Re: GUI interface to Subversion via web browser?
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
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
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
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
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 ” . 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
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
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
Re: SVN access denied when comparing revisions
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
Merge bringing in much more than the specified changes
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: 'Could not get next bucket brigade' error
Boyandin Konstantin wrote: 06.03.11, 20:00, "Nico Kadel-Garcia": But there is also the RPMforge release of subversion-1.6.15 at http://rpmrepo.org/RPMforge/. Enjoy, I put up that one (based on variious previous releases.) I'd urge you to upgrade, ASAP, for a lot of *other* reasons. Thanks, but the above repository doesn't provide 64-bit version of the package. Not sure where you're looking, but you're missing something: [kdeugau@lilbro ~]$ rpm -q subversion subversion-1.6.15-0.1.el5.rfx [kdeugau@lilbro ~]$ cat /etc/redhat-release CentOS release 5.5 (Final) (The .rfx in the release number indicates "RPMForge Extras" - packages that will overwrite the stock CentOS/RHEL ones.) If you prefer to direct-download the package files yourself, they're all in here: http://packages.sw.be/subversion/ -kgd
Re: svnadmin create complains about subrepositories
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
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
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?)
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?
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
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/ or /usr/lib/, along with a matching "use lib" in the executables. -kgd