Re: GUI interface to Subversion via web browser?

[Kris Deugau]

Johan Corveleyn wrote:

What lots of people these days are looking for (myself included) is a
modern "Code Forge" [1][2][3], like GitHub/Lab/... or like the Forgejo
project [4] with its cloud-hosted platform Codeberg [5], but then for
Subversion.

I'd like a modern web interface (hostable on-premise or in the cloud)
that includes:
- Version control repositories (and management thereof)
- Online viewing, searching, diffing, ... (like ViewVC)
- Online editing, committing directly from the web interface
- Ability to manage patches aka pull requests
- Mailing lists and Forums
- Notification system (with ability to individually configure "watch" patterns)
- Issue tracker
- Code reviews
- Wiki
- General (plugable) "Actions" framework
- CI system with buildagents / bots
- Artifact repository
- Enterprise level user management
- ...
- Also accessible from mobile devices of course

Oh, and if possible it should flexibly integrate with external systems
that may already be present in your environment, like if you have a
JIRA issue tracker or wiki or ... you would want to integrate that one
instead of the "default / reference" implementation.


Trac?  https://trac.edgewall.org

I don't think it ticks all of your boxes, but it hits most of them.

-kgd

Re: subversion 1.11.0 on FreeBSD 11.2: ... does not support the HTTP/DAV protocol

[Kris Deugau]

Dr. Rolf Jansen wrote:

The default version of Subversion in the Ports of FreeBSD has been switched 
from 1.10.3 to 1.11.0 in the last week. After running the monthly update of my 
FreeBSD machines I cannot connect to HTTPS repositories anymore.

I submitted a bug report to FreeBSD, see: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232945

The FreeBSD subversion port maintainer, verified that the same issue happens 
with subversion 1.11 on Linux and Windows as well, and he asked me to report 
the issue here.

In the meantime I deinstalled all subversion packages built from the FreeBSD 
ports system, and I built and installed subversion 1.11.0 from the upstream 
sources (thats’s yours) - see below. Needless to say that 1.10.3 does not show 
the issue below, and of course the GitHub server does support HTTP/DAV.


If you check the list archives, you'll see that the thread immediately 
before yours, "Problems accessing GitHub's SVN-bridge with SVN 1.11", is 
about the exact same issue.


Unless I've completely misunderstood that thread, GitHub's custom 
re-implmentation of SVN's HTTP/DAV support is slightly buggy, in that it 
does not actually properly implement the underlying HTTP DAV protocol. 
It's only now become an issue due to Subversion getting stricter about 
checking for DAV protocol elements to better report certain errors.


-kgd

Re: Can import also convert the source to a working copy

[Kris Deugau]

Bo Berglund wrote:

On Thu, 15 Mar 2018 12:03:53 +0100, Johan Corveleyn
 wrote:



See http://subversion.apache.org/faq.html#in-place-import


Seems like the best option is as follows:
-
svn import WiFiConfig /WiFiConfig/trunk --depth files -m "msg"
svn co WiFiConfig/trunk --force WiFiConfig

I.e. First import the directory and then immediately check out the
same with --force

It still takes some time because I think svn needs to download the
files into the cache in the .svn directory.
I have a rather slow connection to the server from where I am...


Unless I misread your original post, the very first option in that link 
looks like a better fit.  To rephrase it somewhat for your case:


1)  Create a repository or a directory in the repository
2)  Create your local files
3)  Check out the empty repository path to your workspace - this won't 
overwrite any of your files

4)  svn add [files]
5)  svn ci
6)  Continue working as usual

This avoids a round trip to the server to push the current files, then 
pull them back down to create the formal SVN working copy with things 
already in it - instead you "check out" an empty directory which should 
be quite fast.


-kgd

Historic merge "done wrong" doesn't work in up to date working copy

[Kris Deugau]

I've been maintaining a set of spam filter rule files in Subversion for 
some time.  On the client side this has been almost entirely with 1.6.x 
on CentOS 5.


I've just recently done a major refresh on my PC, switching to the 
current Debian stable release, with Subversion 1.8.10.


The directory structure I've suddenly found I've been merging 
incorrectly looks like:


dev/
  file1.cf
  file2.cf
  file3.cf
  ...
prod/
  file1.cf
  file3.cf
  ...

(Note a small number of files were added in dev/, but have not been 
copied to prod/.  IIRC the few files added to SVN in dev/ but not prod/ 
got added by the merge, then revert'ed, then OS-rm'ed.)


dev/ and prod/ were created at the same time, in r1.  Files were created 
in dev/, then svn cp'ed to prod/.


With the old 1.6 client, I was able to "svn merge ^/dev" in prod/, and 
it did what I expected;  merge all changes to the relevant files (and 
add the occasional new file) from dev/ to prod/.  merginfo is only 
maintained on the prod/ directory, not individual files.


With 1.8, it's now complaining that dev/ and prod/ have no common ancestor.

What can I do to get unstuck?

-kgd

Re: Compiling Subversion

[Kris Deugau]

Chandra, Ramesh H.S. IN BLR STS wrote:

 I am trying to build the sources. When I execute ./configure
 from the subversion directory, it is giving me the following error:

 root@INBLRKUN1001:/subversion-1.8.13# ./configure
 configure: Configuring Subversion 1.8.13
 configure: creating config.nice
 checking for gcc... gcc
 checking whether the C compiler works... no

You do not have a complete software build environment.  Your compiler is
missing key pieces (or not installed at all).

 So, how do I build subversion and get all the executables?

 NOTE : In our company, there is a policy that internet
 access will not be given to machines having Ubuntu OS. So, I cannot use
 “apt-get install Package name” .

You're going to have to spend a long time working around this
restriction to download the many packages necessary to support building
a complex package like Subversion.  apt-get build-essential would
normally get you started, and that covers a bare minimum ~20+ packages
just for doing general package-building.  I just checked a recent Debian
(Ubuntu is mostly Debian, so the package dependencies are usually almost
identical), and Subversion's own build requirements add another 124
packages.  Also note that this was on a VM I periodically do custom PHP
builds on, so there are probably as many as 30 -dev packages that
overlap with the full set necessary for building Subversion, already
installed.

Or you're going to have to spend quite a bit less time working around
this restriction to download prebuild Subversion packages and the
handful of dependencies it needs to run.

-kgd

Re: Blocking root from SVN repository

[Kris Deugau]

Zé wrote:
 On 08/27/2014 01:49 PM, Les Mikesell wrote:
 It's basically a bad idea to usefile://  access at all for anything
 that might be used under multiple user ids.  Maybe even for a single
 user...
 
 Well, that sucks.  If file:// is not to be used then what are the
 available options to those who only need a local svn repository and
 don't have the option to set up a server?

I've used svnserve instances running under my own user account rather
than use file://.  Access is all via localhost, doesn't require special
privileges, and can run on any port you like, either on a when needed
basis or as a daemon.

-kgd

Re: SVN access denied when comparing revisions

[Kris Deugau]

Philip Martin wrote:
 Subversion 1.7 (but not 1.6) creates svnserv.conf with the following:
 
 ### The sample settings below are the defaults and specify that anonymous
 ### users have read-only access to the repository, while authenticated
 ### users have read and write access to the repository.
 # anon-access = read
 # auth-access = write

The exact text may have changed, but something like this has been
included in the default svnserve.conf for quite a while;  here's the
segment from a repo I've had in its current form since at least ~SVN 1.5
(due to dump/reload to move to a new machine), possibly as far back as 1.2:


[general]
### These options control access to the repository for unauthenticated
### and authenticated users.  Valid values are write, read,
### and none.  The sample settings below are the defaults.
# anon-access = read
# auth-access = write


(TBH I'm not sure why it was changed, it's perfectly clear to *me*...)

I just created a new repo with 1.6.15 to see what it did, and it
produced exactly the same as just above.

-kgd

Re: SVN access denied when comparing revisions

[Kris Deugau]

Daniel Shahaf wrote:
 Kris Deugau wrote on Fri, Mar 22, 2013 at 10:41:27 -0400:
 (TBH I'm not sure why it was changed, it's perfectly clear to *me*...)
 
 You don't say what's unclear about the new text.

I don't see much difference between them at all - obviously others did,
and felt that the older text was less clear.

-kgd

Merge bringing in much more than the specified changes

[Kris Deugau]

I've just come across a very strange merge glitch;  I don't recall
seeing anything like it reported and I'm not sure if I'm just doing
something wrong or not.

$ svn --version
svn, version 1.6.15 (r1038135)

(from the RPMForge repo, on CentOS 5)

I have a project that is very close to a new stable release, but I've
also had a couple of bugs reported that I've fixed in /trunk and I'm
backporting to /branches/stable in the meantime.

I just tried merging the commits for one of these bugfixes, but I'm
getting a lot more code merged than I see from svn diff -c on the
relevant revisions.

The repository is public at https://secure.deepnet.cx/svn/dnsadmin;  I'm
trying to merge revisions 417 and 418 from /trunk to /branches/stable.

Merging r417 I end up with an extra ~150 new lines in the third fragment
- not part of the commit in r417, so far as I can see, and which I'm
pretty sure was committed quite a while ago (before ~r330 or so).

-kgd

Re: svnadmin create complains about subrepositories

[Kris Deugau]

Fabian Richter wrote:

To be frank: I dont see why I am not able to create nested repos


A Subversion repository, from the point of view of the filesystem it 
lives on, is intended to be (mostly) a black box that you interact with 
through the SVN repository access layer you've configured.



or
what you mean that they need to be peers...


You can have a set of repositories side-by-side like so:

/path/to/repo1
/path/to/repo2
/path/to/repo3

You can't put another repository inside another, *at the same filesystem 
level*, like so:


/path/to/repo1
/path/to/repo1/repo2
/path/to/repo1/repo3

You *can*, if you really want, add a filesystem location containing a 
SVN repository as content to an existing repository...  although how 
you'd access it usefully is another matter.



You say a repo folder can have the content i need it to have. I need
them to have other repos. To be sure we are talking about the same
thing:

/repos1
/repos1/repos2
/repos1/repos3


Can you expand on why you really need to do this?  Why can't you use 
folders in a single repository, or just leave /repos1 as a regular 
filesystem directory, that contains repositories?


To ask things a bit differently, does arbitrary content under the URL 
that leads to /repos1 need to be version-controlled (eg, /repos1/file1), 
or is all the version-controlled content one layer deeper 
(/repos1/repos2/file1)?



something like that. And the comparison to mysql DB doesnt make sense,
because in a dbms I am able to deklare multiple databases for the same
server or root dir, thats what is apparently not possible for svn...


Well, when you create a MySQL database, the tabledefs at least all go 
into /path/to/mysqldir/database2 - you can't put them in 
/path/to/mysqldir/database1/database2.


Subversion is pretty much the same, except you as administrator have 
somewhat more control of the filesystem location of each repository; 
it's perfectly possible (if inadvisable unless you need to isolate repo 
groups) to put a couple of repositories under /path/to/repgroup1, and 
another group under /another/place/repogroup2, and a lonely one off by 
itself in /some/other/repo.


-kgd

Re: Periodically merge between trunk-branch and branch-trunk

[Kris Deugau]

Daniel Albuschat wrote:

I'd like to create a branch from trunk and periodically merge trunk
into my branch to stay up to date with what happens in trunk.
At some point, the feature in my branch reaches a kind of stability
that is OK for trunk, so I merge it back to trunk.
The difference to the standard situation is that I want to continue
working on the branch, because the feature is not completely finished,
yet, or it needs further enhancement.
Currently the only solution I see is to reintegrate the branch to
trunk and then re-create the branch. This has the shortcoming that all
developers working on the branch have to switch to the new branch
(although it is the same URL) to be able to work with it, right? This
is ok when I'm working alone on my branch, but with a development
team, it becomes tricky to make sure that everyone properly switch to
the new branch.


This is covered in the book:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice

-kgd

Re: svnsync_test.py fails: wrong version of SQLite library

[Kris Deugau]

Michael J. Bauer wrote:
I see no SVN version 1.6 RPM in RPMForge.  It's the first place I looked 
before trying to build it by hand.


Very strange: (trimmed a little)

[kdeu...@lilbro ~]$ yum list |grep subversion
subversion.x86_64 1.6.13-0.1.el5.rf   installed
[kdeu...@lilbro ~]$ yum list rpmforge-release
rpmforge-release.x86_64   0.5.1-1.el5.rf  installed

(FWIW, there seems to be an updated rpmforge-release package.)

I've had several previous 1.6 SVN versions from RPMForge, and I expect 
I'll see 1.6.15 within a week or so.


-kgd

Set mergeinfo for branches previously crossmerged with svn 1.5 (was Re: Declare branches to be equal?)

[Kris Deugau]

Anyone?

Kris Deugau wrote:
I've got a repository that saw moderate use for several years, then the 
project reached a stable point.


I upgraded SVN as I went along, however on my primary dev system I've 
been stuck with a 1.4 client (CentOS 4).


Recently, I've switched to a different system for further development on 
this project, made a number of commits to bring /trunk and 
/branches/stable into sync, and done further development on /trunk.


I'd like to merge my changes from /trunk now, but I'd also like to make 
use of the merge tracking features that have been added since SVN 1.4.


Is there a way to do svn merge --record-only that will result in 
/trunk and /branches/stable being considered equivalent and/or fully 
merged as of a given revision?


Historically, some changes have been made first on /trunk, then merged 
to /branches/stable (mostly new development);  others have been made the 
other way around (bugfixes).  :/


I'd like to avoid walking back over the log to explicitly run svn merge 
--record-only rA:B source dest for each of these historical merges.


-kgd

Declare branches to be equal?

[Kris Deugau]

I've got a repository that saw moderate use for several years, then the 
project reached a stable point.


I upgraded SVN as I went along, however on my primary dev system I've 
been stuck with a 1.4 client (CentOS 4).


Recently, I've switched to a different system for further development on 
this project, made a number of commits to bring /trunk and 
/branches/stable into sync, and done further development on /trunk.


I'd like to merge my changes from /trunk now, but I'd also like to make 
use of the merge tracking features that have been added since SVN 1.4.


Is there a way to do svn merge --record-only that will result in 
/trunk and /branches/stable being considered equivalent and/or fully 
merged as of a given revision?


Historically, some changes have been made first on /trunk, then merged 
to /branches/stable (mostly new development);  others have been made the 
other way around (bugfixes).  :/


I'd like to avoid walking back over the log to explicitly run svn merge 
--record-only rA:B source dest for each of these historical merges.


-kgd

Re: Perl can't find my libraries when run via the subversion post-commit script

[Kris Deugau]

Craig Thayer wrote:

David,

Thank you for your reply.

Yes, I have tested the script on the Subversion server and it runs just fine.


As root, or as the user the repo is accessed as?

/root isn't usually accessible by any user *other* than root in my 
experience, and most of the documentation assumes that svnserve or 
Apache (and therefore, all of your hook scripts) are running as one of:

- dedicated svn user
- Apache runtime user
- various non-root users if using svn+ssh with system users


 And I agree it is obvious that Perl is including the directories to my 
libraries (so the use lib statements are working as designed as you stated).  
However, it is Perl that is complaining that it can't find my libraries even 
though they are clearly in the @INC path.  I have never run into this situation 
before and I believe it has to do with the fact that the Subversion hook is 
running with no environment defined, but why it makes Perl not able to find my 
libs ONLY when it runs as a Subversion hook I haven't a clue.


I tried a quick test creating an empty module in /root:

===
package Testme;

our $foobar = foo!;
===

then ran

perl -e 'use lib /root; use Testme;'

as root and as non-root.

Running as root succeeded, non-root failed with Can't locate Testme.pm 
in @INC


I suspect you'd still have the issue even if you hardcoded the absolute 
path;  Perl can't find the module because it can't read the directory 
it's in.



I have temporarily resolved the problem by moving my libraries to the 
/usr/lib/perl5/site_perl path (which I didn't want to do) which is predefined 
by my Perl installation in @INC.  The script now runs via the Subversion hook 
and finds my libraries just fine.  I would, however, like to understand what 
causes Perl to not recognize my added paths to @INC when it runs as a 
Subversion hook.


perl -V should show you the standard include paths;  custom local 
modules intended for general use should usually go somewhere under 
/usr/local/lib, and I've usually seen custom modules for specific uses 
get bundled into /usr/share/app or /usr/lib/app, along with a 
matching use lib in the executables.


-kgd