RE: Individual file merge . Merging a newly added file
> -Original Message- > From: Lorenz [mailto:loren...@yahoo.com] > Sent: Wednesday, August 2, 2017 1:34 AM > To: users@subversion.apache.org > Subject: Re: Individual file merge . Merging a newly added file > > JP wrote: > >I am trying to merge a newly added file . I am getting the following > >error . > > > >|svn merge -c123 > >|https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.sv > >|n.domain%2Fsvn%2Ffoo%2Fbranches%2Fbar%2Fnewfile.txt=02%7C01%7Cjre > >|edick%40incomm.com%7Cbf08bacf2e7f48e9062108d4d9683be1%7Cd08e5403b1c94d > >|bfaf91bab966a84dea%7C1%7C0%7C636372489093013309=%2BS0P8L4moTaajr > >|L5XQS%2BIc4ln8hyEci1GdDKhYkh1eE%3D=0 ./newfile.txt > >svn: E29: Merge target './newfile.txt' does not exist in the > >working copy > > > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.svn.domain%2Fsvn%2Ffoo%2Fbranches%2Fbar%2Fnewfile.txt=02%7C01%7Cjreedick%40incomm.com%7Cbf08bacf2e7f48e9062108d4d9683be1%7Cd08e5403b1c94dbfaf91bab966a84dea%7C1%7C0%7C636372489093013309=%2BS0P8L4moTaajrL5XQS%2BIc4ln8hyEci1GdDKhYkh1eE%3D=0 > > is in status "A" > >. How can I do such merges . > > > adding a file is a change to the parent directory. Translation: The newly added newfile.txt is completely unrelated to the previously existing newfile.txt you are merging from. Either a) Remove the newly added newfile.txt and instead do a 'svn copy ...' of the previously existing newfile.txt to the new location. This preserves ancestry and makes merging easier. Or b) If the newly added newfile.txt really should be completely independent/unrelated to the previously existing newfile.txt, then you will need to use a "2-URL merge" to merge the previously existing newfile.txt into the newly added newfile.txt. Refer to "svn help merge". >From "svn help merge": 3. This form is called a '2-URL merge': ... The target branch may be the same as one or both sources, or different again. The three branches involved can be completely unrelated.
RE: upgrading server
>> Does anyone know how long it would take to export the repository of this >> size? This will give us an estimate how long to schedule down time and cut >> off time. Svnsync is the easy option. If you insist on doing a dump/load, then a) you can time a test run of a dump/load, and b) "svnadmin dump" allows you to specify revision ranges which means you can do incremental dumps. You can dump/load the bulk of the repo now and then during the migration, run another dump/load to catch any new commits. http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate The only caveat I can think of is if someone changes revision properties (e.g. the commit message) between the time of the initial dump and the migration. But you can track/prevent those with a hook script. (And is another reason why svnsync is preferred.)
RE: svn feature addition?
> From: Eggler, Ron (GE Energy Connections) [mailto:ron.egg...@ge.com] > Sent: Thursday, June 1, 2017 7:44 PM > To: users@subversion.apache.org > Subject: svn feature addition? > > Hi There, > > I am looking for the following features in svn: > - When you do svn commit, instead of automatically submitting all changed > files in the directory, in the dialog where you enter the commit message (if > -m flag is not used), is there a feature to uncheck any files that should not > be committed/select files to be committed? > - Is there an option to inspect each file further line-by-line for lines > that have changed to either be selected or excluded from the commit? > I am interested to potentially work on patches that would extend svn with the > above functionality if not present already, does anyone know? It seems like > these options would be really useful. What about working on a (temp) branch and then selectively merging what you want over? Steps would be: Make temp branch Switch to temp branch Commit all Switch to main branch Selectively merge files/lines from temp to main Commit main. "Copy merge" from temp to main to overwrite workspace with stuff from temp in order to recreate modified files (i.e. files that you only merged a few lines from) that existed initially. Rm temp branch Keep working. Most of that should be scriptable.
RE: How to checkout only the changes
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: Thursday, March 30, 2017 3:41 PM > To: Andrew Reedick > Cc: horst.schl...@gmx.de; users@subversion.apache.org > Subject: Re: How to checkout only the changes > > 'vsvn diff --summarize' or 'svn log -qv' would be better. (They're O(1) as > opposed to O(revision size).) Unfortunately, neither one differentiates between directories and filenames (unless you go with --xml.) And exporting a dir will grab a bit more than what we wanted. Unless of course the contents of new directories count as changes. Which would be a requirements question for the OP.
RE: How to checkout only the changes
New and improved and simplified version. Uses 'svn log --diff' to get the files that changed. Again, only lightly tested. (The previous script assumed that the order of the xml attributes didn't change and it did. Ooops.) I used perl instead of sed due to sed version silliness in regards to tabs; so feel free to the perl equivalent sed commands to remove the trailing "\t (revision 12345)" from the "svn log --diff ... | grep '^+++' " output. Remove the two echo commands to actually run the mkdir/export commands. Edge case: I didn't test how 'svn log --diff' handles deleted files. #!/bin/bash REV=$1 SVNREPO=$2 svn log --diff -r $REV "$SVNREPO" | grep '^+++' | perl -pe 's/^\+\+\+ //; s/\t.*$//' | while read i do D=./`dirname "$i"` echo mkdir -p "$D" echo svn export --force "$SVNREPO/$i@$REV" "$D/" done -Original Message- From: horst.schl...@gmx.de [mailto:horst.schl...@gmx.de] Sent: Wednesday, March 29, 2017 9:28 PM To: users@subversion.apache.org Subject: Re: How to checkout only the changes On 03/27/2017 10:08 AM, Andrew Reedick wrote: >> From: horst.schl...@gmx.de [mailto:horst.schl...@gmx.de] >> Sent: Friday, March 24, 2017 4:04 PM >> To: users@subversion.apache.org >> Subject: How to checkout only the changes >> >> >> Is there a way to export only the changes, that occured in a specific >> revision? Like export or checkout only the added or modified files in their >> respective paths? Deletions and cheap copies cannot be treated that way, >> obviously. Please CC as I am not subscribed. > > FYI, 'svn copy' counts as an Add. That may or may not be a concern? > > Mostly Untested But Seems to Work in the Average Case(tm), so user beware: > > #!/bin/bash > > # usage: foo.sh 1234 http://svn_server/repo_name > REV=$1 > SVNREPO=$2 > > svn log -qv -r $REV $SVNREPO > > # Yes we're grepping on XML because :laziness: > # And we're using perl because I can't be bothered with sed/awk subtleties > svn log -qv --xml -r $REV "$SVNREPO" | perl -ne 'chomp; $a=1 if /^ > action="[AD]"/; print "$1\n" if ( $a && /^ kind="file">(.*)<\/path>/ ); > $a=0 if /<\/path>/;' | while read i > do > D=./`dirname "$i"` > mkdir -p "$D" > svn export --force "$SVNREPO/$i@$REV" "$D/" > done > The script just drops to the shell with exit code 0. My perl knowledge is very limited, but to debug I executed this $ echo "action=\"A\">/trunk/text.txt" | perl -ne 'chomp; $a=1 if /^ action="[AD]"/; print "$1\n" if ( $a && /^ kind="file">(.*)<\/path>/ ); $a=0 if /<\/path>/;' I assume that is supposed to do something but for me it just drops to the shell with exit code 0.
RE: How to checkout only the changes
> From: horst.schl...@gmx.de [mailto:horst.schl...@gmx.de] > Sent: Friday, March 24, 2017 4:04 PM > To: users@subversion.apache.org > Subject: How to checkout only the changes > > > Is there a way to export only the changes, that occured in a specific > revision? Like export or checkout only the added or modified files in their > respective paths? Deletions and cheap copies cannot be treated that way, > obviously. Please CC as I am not subscribed. FYI, 'svn copy' counts as an Add. That may or may not be a concern? Mostly Untested But Seems to Work in the Average Case(tm), so user beware: #!/bin/bash # usage: foo.sh 1234 http://svn_server/repo_name REV=$1 SVNREPO=$2 svn log -qv -r $REV $SVNREPO # Yes we're grepping on XML because :laziness: # And we're using perl because I can't be bothered with sed/awk subtleties svn log -qv --xml -r $REV "$SVNREPO" | perl -ne 'chomp; $a=1 if /^ action="[AD]"/; print "$1\n" if ( $a && /^ kind="file">(.*)<\/path>/ ); $a=0 if /<\/path>/;' | while read i do D=./`dirname "$i"` mkdir -p "$D" svn export --force "$SVNREPO/$i@$REV" "$D/" done
RE: how to detect read-only branch from client?
Not a complete solution, but it's a start. Craft a "svn mkdir" that includes the url to test and a url that will always fail, e.g. svn mkdir -m "" http://server/repo/dir2test/a http://server/repo/readonly/z However, it looks like the urls are sorted and then processed in sort order (including for svnmucc.) So you need your test url to come before your "will always fail" readonly url. Getting the sorting figured out is left an exercise to the reader. Maybe someone else knows of a way to ensure that the "always fail" readonly url gets checked last regardless of windows sorting, linux sorting, LC_ALL/LC_COLLATE settings, etc. -Original Message- From: Torsten Mueller [mailto:muelle...@runbox.com] Sent: Monday, February 13, 2017 11:51 AM To: users@subversion.apache.org Subject: how to detect read-only branch from client? I write a script getting sources from one repository, doing a build and other time consuming things and then committing the results into another repsitory. The problem is: the detination side is "managed" which means that I must expect read only branches there. They use the path based authentication feature (see VisualSVNServer) without any communication. They want to close a branch for commits, that's enough communication. But in my case it would be very bad to start a process which runs for an hour or longer and then fails because it can't do the final commit. How can I detect if a path in the destination directory is read only without modifying it? My first guess was to use "svnmucc propdel" to delete a property which doesn't exist. This works great on a branch which is read only. But on the other side it creates always a revision on normal branches. That's not good. What can I do? T.M.
RE: [Linux] Hook hashbang hardships
> Hello! I've been having trouble getting my own pre-revprop-change hook script > to work. Svn was refusing any change to a revprop with the following error: > > svn: E165001: Revprop change blocked by pre-revprop-change hook (exit code 1) > with no output. > > > Until I found out that the issue was in the script's shebang: > > #!/bin/bash -e > > which wouldn't work. Had to remove ' -e'. Is this expected behaviour or is > there something wrong with svn (version 1.9.4 (r1740329) on > Linux/x86_64) ? Bash doesn't appear to have a "-e" option. (There is a "-e" test to check if a path exists, but that's not a command line arg you pass in to bash.) /bin/bash --help man bash https://linux.die.net/man/1/bash
RE: Creating and Verifying a Reliable backup
> From: Michael Schwager [mailto:mschw...@gmail.com] > Sent: Wednesday, June 22, 2016 10:25 AM > To: users@subversion.apache.org > Subject: Re: Creating and Verifying a Reliable backup > > Following is an update to my question of Jun 1, where I ask the following > question: > ... snip verify/backup/verify/rsync/verify script... > If you're not already doing it, you might want to pack your repos in order to the make the backups and/or copying faster. Working on thousands of small files is incredibly slow/inefficient. http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.fsfspacking However, I'm not sure what the pros/cons of packing are in regards to rsync.
RE: which version control supports file locking and who has it locked
> From: Doug Robinson [mailto:doug.robin...@wandisco.com] > Sent: Monday, June 13, 2016 4:49 PM > To: Johan Corveleyn > Cc: Mark McKeown; Andreas Stieger; users@subversion.apache.org > Subject: Re: which version control supports file locking and who has it locked > > > I'm not sure about Perforce's implementation. However, just for > comparison: with ClearCase Dynamic Views you can *not* edit the file > without a checkout. The Dynamic View implementation is via an actual > OS file system so you can't beat it. And everyone can see that checkout. What about eclipsed files? And never forget that Someone can always copy the file out of the view/workspace to make changes to it because they're in a rush to leave for vacation. Of course such a person, after coming back from vacation, would *never* copy their week old modified file back in to the workspace/view in order to check in their changes after the lock is released thus undoing the previous week's work of commits. Point is, you can't completely idiot proof anything because there's always one idiot who's smarter than you.
RE: could subversion server 1.7.x work with subverison client 1.8.x ?
Go here https://subversion.apache.org/docs/release-notes select a release and then look at the “Feature Compatibility Table” which will specify which features require what server/client version. However, as already noted, basic features will work with any 1.x client and 1.x server. From: Leon Huang [mailto:hzlian...@gmail.com] Sent: Sunday, September 27, 2015 9:56 AM To: users@subversion.apache.org Subject: could subversion server 1.7.x work with subverison client 1.8.x ? Dear developers of subversion: Hello! Question 1: If the version of subversion server is 1.7.10, but my subversion client is 1.8.5, is there any problem? Question 2: At first, use subversion 1.7.10 client to checkout a work-copy. Then subversion 1.8.x client to upgrade the work-copy from 1.7 to 1.8, from then on I just use subversion 1.8.x client to operate this work-copy, is it compatible？ I hope that you can help me! Thank you! Looking forward to your reply! Have a nice day! Regards！ From Leon Huang Hangzhou China
RE: preventing recording misaligned mergeinfos
I was under the impression that subversion now automatically takes subtree mergeinfo into account: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.stayinsync.subtree -Original Message- From: Stefan Hett [mailto:ste...@egosoft.com] Sent: Friday, August 28, 2015 9:19 AM To: 'subversion' Subject: preventing recording misaligned mergeinfos Hi, I'm currently checking-out ways to prevent the creation of misaligned mergeinfos in SVN. My current solution would be to add a pre-commit hook to prevent any mergeinfo records on any but the top-most node (aka: trunk or a branch). While this would prevent most cases which let to misaligned mergeinfos, it's certainly not exactly what I want/need. Does anybody have an idea for a better/more precise solution/approach? -- Regards, Stefan Hett, Developer/Administrator EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany Tel: +49 2405 4239970, www.egosoft.com Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
RE: Two-step merge ok, one-step merge conflicts
-Original Message- From: Timur Khanipov [mailto:khani...@gmail.com] Sent: Wednesday, August 19, 2015 1:20 PM To: users@subversion.apache.org Cc: Иван Коптелов Subject: Two-step merge ok, one-step merge conflicts Hi folks. I faced the following problem. The command svn merge -r 3:4 -r 4:5 ^^/trunk works smoothly while command svn merge -r 3:5 ^^/trunk results in a text conflict. This seems like a buggy behavior (since the two merges are equivalent). Same behavior in 1.8.10 (r1615264) on windows. However, if you change the svn:eol-style to CRLF, them merge -r 3:5 works without a conflict. It looks like native with the merge -r 3:5 causes a conflict because of eol changes to the file in the middle of the merge process? Also note, that with native the merge conflict appears to be with the EOLs and not with the text change you made.
RE: Tool for upgrading many svn repos with dump/load?
Since you're moving from windows to Ubuntu, you can run the dump/load process over ssh to avoid having to deal with bloated dump files: http://martin.ankerl.com/2006/01/24/svnadmin-dump-and-load-over-ssh/ (You can use mobaxterm (http://mobaxterm.mobatek.net/ ) on Windows, which is a Cygwin bash shell in a self contained exe. Very, very convenient.) You can also use ssh to create the empty repos remotely. As for merging the configurations, short of creating a temp repo in which you check in the default repo's auth/conf/hook files into trunk, and then checking in your live repo auth/conf/hook scripts into a branch off of trunk, then merging the branch into the trunk to effectively merge the files and then copying the merged files to the new repos, I don't know of anything. =( -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Friday, July 10, 2015 3:53 AM To: users@subversion.apache.org Subject: Tool for upgrading many svn repos with dump/load? Hi all, are you aware of any tool that is able to upgrade many SVN repos by creating a new empty default repo, dump a corresponding old repo, load that dump into the new one AND is able to MERGE the configuration? I have some dozen repos hosted by svnserve with independent realms, users, authz rules and such. This configuration could be just copied, but I would prefer merged default configs for documentation purpose and such. I've created something similar in the past using Powershell, but without the merge stuff and it just don't work on our now used Ubuntu servers. Before I roll my own new script, I wanted to make sure that I don't miss anything because I didn't found something mentioned on the net. Thanks! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Subversion for Windows
SubversionEdge from collabnet is a pre-packaged solution that takes most of the effort out of setting up svn + http/https: http://www.collab.net/products/subversion From: Novinsky, Stanley J. [mailto:stan.novin...@jhuapl.edu] Sent: Wednesday, May 06, 2015 5:54 PM To: users@subversion.apache.org Subject: Subversion for Windows Hi, I have a question,,, I Installed Subversion for Windows on a VM and set up a project using TortoiseSVN We need to access the SVN from remote offices vis https What is the process to set up the remote access allowing users to access the project? Thanks Stan
RE: Svn rename doesn't copy custom properties
Works for me. svn, version 1.8.10 (r1615264) Windows 7 C:\Users\jdoe\workspace\foobarsvn pl -v A.txt Properties on 'A.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c C:\Users\jdoe\workspace\foobarsvn rename A.txt AA.txt A AA.txt D A.txt C:\Users\jdoe\workspace\foobarsvn pl -v AA.txt Properties on 'AA.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c C:\Users\jdoe\workspace\foobarsvn st D A.txt moved to AA.txt A +AA.txt moved from A.txt From: Dan Ellis [mailto:danelli...@gmail.com] Sent: Wednesday, April 29, 2015 7:23 PM To: Daniel Shahaf Cc: Subversion Users Subject: Re: Svn rename doesn't copy custom properties OK, so it gets stranger... I admit I changed the property names a bit to simplify them. When I ran the simplified names, it does work. Here's the exact example that does not work: c:\Project_files\sandbox_v2svn pl -v A.txt Properties on 'A.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c c:\Project_files\sandbox_v2svn rename A.txt AA.txt A AA.txt D A.txt c:\Project_files\sandbox_v2svn pl -v AA.txt c:\Project_files\sandbox_v2svn pl -v REN.txt
RE: Svn rename doesn't copy custom properties
From: Dan Ellis [mailto:danelli...@gmail.com] **Brane asked: There's no REN.txt in your example. **Anyway, please tell us which version of the client you're using (svn --version) and where it came from. I meant to exclude that as its not relevant, was trying to point out the empty response. Sorry everyone, I'm not on the mailing list proper, I'd appreciate being cc:d. This is the client version, being whatever was packaged with the version of TSVN. svn, version 1.8.9 (r1591380) compiled May 6 2014, 20:28:35 on x86-microsoft-windows Maybe there's a problem with inherited properties that ignore certain files or Something(tm)? Can you create a new (empty) repo and re-run the test in it?
RE: Dealing with very old repo format (version 1)
-Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Are we talking about the repository format or the FSFS format here? If repos/db/fs-type says fsfs then the repository format (repos/format) is probably 3 and you're talking about repos/db/format, yes? The distinction is important. Yes, I'm referring to db/* files. $ more format fs-type :: format :: 1 :: fs-type :: fsfs In any case, 1.8 /should/ be able to dump an FSFSv1 repository, and the repos/db/current file should exists; it's been around since FSFSv1. You can try recreating it; the format is described here: https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure To find the youngest revision, look for the highest-numered file in repos/db/revs. If you're just going to dump the repository, it should be safe to set the next-node-id and next-copy-id to some large number, say 99; but I wouldn't recommend trying to commit to the repository. Please report if the above works or I'm just talking through my hat. :) -- Brane Good News: Recreating the db/current file worked in that it allowed 'svnadmin dump' to run. Bad News: However, it seems that I have bigger issues: * Dumped revision 109662. svnadmin: E720002: Can't open file 'devel_copy\db\revprops\109663': The system cannot find the file specified. When I sort the files in db/revs numerically, I see gaps in the revs: 109661 109662 109668 109734 ... 109735 157939 157940 157941 159433 159607 160600 160601 162409 And 'ls | wc -l' in dev/revs shows that there are 141,768 files, but the highest rev in db/revs is 162409... *sigh* I guess I can try piecemeal dumps. Thanks for the help everyone, but I'm thinking my missing db/current file is a symptom of the repo being mangled (probably due to inadequate backup procedures or a bad restore from tape. Rev 1 is from 2006, and the repo was just around for reference so no real worries.)
RE: Dealing with very old repo format (version 1)
-Original Message- From: Joseph Bruni [mailto:jbr...@icloud.com] Sent: Tuesday, April 28, 2015 5:09 PM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: Dealing with very old repo format (version 1) On Apr 28, 2015, at 2:03 PM, Andrew Reedick jreed...@incomm.com wrote: Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0. Hi Andrew, I'm guessing your old format was built using the BerkeleyDB backend since many of the earlist repos defaulted to BDB until FSFS came around. If you build your svn with BDB, does it still complain? Forgot to mention, db\fs-type is fsfs so BDB isn't (shouldn't) be an issuse. On the plus side, I found some ancient installers: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=469expandFolder=469folderID=11149
RE: Dealing with very old repo format (version 1)
-Original Message- From: Andrew Reedick [mailto:jreed...@incomm.com] On Apr 28, 2015, at 2:03 PM, Andrew Reedick jreed...@incomm.com wrote: Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0. Hi Andrew, I'm guessing your old format was built using the BerkeleyDB backend since many of the earlist repos defaulted to BDB until FSFS came around. If you build your svn with BDB, does it still complain? Forgot to mention, db\fs-type is fsfs so BDB isn't (shouldn't) be an issuse. On the plus side, I found some ancient installers: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=469expandFolder=469folderID=11149 Looks like the fsfs type was introduced in 1.1. However, a 1.1.4 client fails with svn: Can't open file 'devel/db/current': The system cannot find the file specified. And the 1.0.9 client fails with svn: Berkeley DB error while opening 'nodes' table for filesystem devel - Copy/db: No such file or directory Looks like I need a bigger hammer.
Dealing with very old repo format (version 1)
Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0.
svnsync: E160016: Path ... not present
Anyone familiar with this svnsync bug/issue? I didn't see anything substantive via google or in the svn issue tracker. C:\svnsync sync svn://localhost/devel_mirror Transmitting file data .. svnsync: E160016: Path 'DigitalDelivery/DigitalSecure/ddp/aps/shared/apss-ddp-ejb/branches/apps-ddp-ejb-jboss-upgrade' not present I have a master server (svn 1.8.3) pushing to a mirror (svn 1.8.11) and to a 2nd mirror on my localhost (svn 1.8.10), both of which return the same E160016 error when running svnsync sync. To make things really interesting, the log entry on both mirrors for the missing directory is a tad off: Master: $ svn log -v -r 305908 http://my.svn.server/svn/devel r305908 | jdoe | 2015-03-24 12:04:06 -0400 (Tue, 24 Mar 2015) | 1 line Changed paths: A /DigitalDelivery/DigitalSecure/ddp/aps/shared/apss-ddp-ejb/branches/apps-ddp-ejb-jboss-upgrade Mirror: $ svn log -v -r 305908 file:svn/csvn/data/repositories/devel_mirror.bad r305908 | (no author) | (no date) | 1 line Mirror Local: C:\svn log -v -r 305908 svn://localhost/devel_mirror r305908 | (no author) | (no date) | 1 line The dir doesn't exist on the mirrors, e.g. C:\svn ls svn://localhost/devel_mirror/DigitalDelivery/DigitalSecure/ddp/aps/shared/apss-ddp-ejb/branches/apps-ddp-ejb-jboss-upgrade svn: warning: W160013: URL 'svn://localhost/devel_mirror/DigitalDelivery/DigitalSecure/ddp/aps/shared/apss-ddp-ejb/branc hes/apps-ddp-ejb-jboss-upgrade' non-existent in revision 309012 svn: E29: Could not list all targets because some targets don't exist Thus, the sync fails when it tries to push a later revision that contains modified files under the not present directory. So how does svnsync not correctly push a revision to two mirrors on two different computers?
RE: svnsync: E160016: Path ... not present
-Original Message- From: Andrew Reedick [mailto:jreed...@incomm.com] Sent: Friday, April 24, 2015 1:26 PM To: users@subversion.apache.org Subject: svnsync: E160016: Path ... not present Anyone familiar with this svnsync bug/issue? I didn't see anything substantive via google or in the svn issue tracker. C:\svnsync sync svn://localhost/devel_mirror Transmitting file data .. svnsync: E160016: Path 'DigitalDelivery/DigitalSecure/ddp/aps/ shared/apss-ddp-ejb/branches/apps-ddp-ejb-jboss-upgrade' not present Never mind. It looks like the empty revisions were due to the sync user not initially having read access to that particular part of the tree. So svnsync synchronized empty placeholder revisions.
svn log --xml -g doesn't identify a reverse merge but svn log -g does
I need a sanity check. Is this an oversight that needs to be corrected, or am I missing something? Problem: svn log -g will explicitly identify a reverse merge, however, when specifying xml output (svn log -g --xml) no such identification is made. Example: In this case, r13 on branches/test was merged to trunk (which created r15 on trunk.) I then reverse merged the r13 change out of trunk using svn merge -c -15. a) svn log -g -v explicitly states that r13 was Reverse merged via..: r17 | andrew | 2014-01-16 14:41:15 -0500 (Thu, 16 Jan 2014) | 1 line Changed paths: M /trunk M /trunk/a.txt svn merge -c -15 . r13 | andrew | 2014-01-16 14:37:17 -0500 (Thu, 16 Jan 2014) | 1 line Changed paths: M /branches/test/a.txt == Reverse merged via: r17 branch 3 b) However, svn log -g -v --xml does not indicate that it was a reverse merge: logentry revision=17 authorandrew/author date2014-01-16T19:41:15.571931Z/date paths path action=M prop-mods=true text-mods=false kind=dir/trunk/path path action=M prop-mods=false text-mods=true kind=file/trunk/a.txt/path /paths msgsvn merge -c -15 ./msg == logentry revision=13 authorandrew/author date2014-01-16T19:37:17.531316Z/date paths path text-mods=true kind=file action=M prop-mods=false/branches/test/a.txt/path /paths msgbranch 3/msg /logentry /logentry Andrew Reedick CBeyond Cloud Development, SCM O: 678.486.8163
RE: subversion windows passwords not stored
Do you have write access to the dirs/files in %APPDATA%\Subversion\auth\...? I’ve seen cases on the Unix side where the cached auth files magically become readonly (444) which prevents password caching. Very annoying. From: darkdragon [mailto:darkdragon-...@web.de] Sent: Tuesday, January 07, 2014 1:43 PM To: users@subversion.apache.org Subject: subversion windows passwords not stored I am using Subversion 1.8.5 under Windows 8.1 and my passwords (http repo) are not stored. I tried the default config (default options) and also explicitly setting all related options. Both did not work. I also tried setting the option manually via --config-option - but also without success! Further, I tried adding a server specific configuration. Options like username were applied, options like store-passwords did not make a change. During my research, I noted that only the %APPDATA%\Subversion directory exists (not the site-wide configuration and none of the registry keys exists). Has anyone else Windows an can confirm this? Thanks!
RE: Keyword expansion from merged changes
-Original Message- From: James Hanley [mailto:jhan...@dgtlrift.com] Sent: Saturday, January 04, 2014 2:47 AM To: Ben Reser Cc: users@subversion.apache.org Subject: Re: Keyword expansion from merged changes So in my opinion I don't think this is a good suggested feature. Fair enough, and one of the workarounds you previously mentioned may be useful, but in my opinion there is still gap between keywords and merge history even if this specific feature proposal is not a desired solution to close that gap. Where do we go from here? Nowhere. soapbox IMHO, you should change your process to not rely on keywords, for the simple reason that merge edge-cases require human intervention and/or interpretation (e.g. extra changes made in the merge revision, non-trivial conflict resolution, partial merges, reverse merges, cherry picked merges, record only merges, etc.) The svn tools (e.g. 'svn diff' or 'svn mergeinfo --show-revs eligible') simply help to notify you that there may be a problem that needs to be investigated. A difference between exported code bases could be acceptable, but only a human can make that determination. Missing merges may be okay if the skipped revisions represent an unwanted or incomplete feature, (i.e. you don't want to merge incomplete work to trunk.) From a previous post: our need would be for during the release process for validating all changes are completely synchronized and that there are no missing changes between branches, but aside from our need, it just doesn't seem right that there would show differences between the exported branches There are two types of bicycle riders: those who have fallen and those who have yet to fall. Right now you have a very easy to merge code base since you can safely make the assumption that exported merges should be identical. But trust me, you will eventually hit a merge edge case which completely negate your ability to maintain that assumption. Your process, workflow, and issue/defect/bug/ticket tracking system should be instrumental in ensuring that work is being tracked (in addition to 'svn mergeinfo' and 'svn diff'.) A merge aware keyword just isn't enough, because even if a merge aware keyword were implemented, it would become useless once you hit a merge edge case. /soapbox
RE: log reporting some strange (for me) merged paths
From: Pablo Beltran [mailto:pbeltr...@gmail.com] Sent: Friday, December 20, 2013 3:29 AM To: users@subversion.apache.org Subject: log reporting some strange (for me) merged paths (Q.1)Why is the M /sis/branches/JDK7/ide-project/NetBeans/nbproject/genfiles.properties present in the merge log (r1400370)whether it is not in the (r1400377) log. Does it mean that the genfiles.properties@1400370 was merged into the /sis/branches/JDK6@1400377 but it was just the same file and therefore it was not modified in the r1400377? The file wasn't changed during the merge so it doesn't get committed, so it doesn't show up in r1400377. The file is listed the 'merged via' because 'svn log' includes all files/changes for a revision. 'svn log -g' doesn't automagically trim any unmerged changes from the merged via revision. (Q.2) What does it mean? It looks like the /sis/branches/JDK6 directory was merged against itself... Merges tend to change the svn:mergeinfo property on directories. Try doing a 'svn diff -r 1400377 /sis/branches/JDK6'. Use the '--properties-only' switch to make it clearer.
RE: Help with post-commit script
-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
Sent: Tuesday, December 03, 2013 1:14 PM
To: Andrew Reedick
Cc: Alfred von Campe; users@subversion.apache.org
Subject: Re: Help with post-commit script
svnlook changed ... $CHANGED_LIST || exit 1 cat $CHANGED_LIST | sed
's/^//g' | perl -ne 'print $1$2\n if
/^(trunk)\/|^(branches\/[^\/]*)\//' | sort -u | xargs -n 1 -i svnlook
propget $REPOS_PATH my:filelist_prop {} $FILES_TO_REPORT_ON ||
exit 1
cat $CHANGED_LIST | while read i
'read' splits on whitespace, so filenames that contain spaces won't
DTRT.
Close. Read will drop leading/trailing whitespace. It does respect internal
whitespace though.
The fix is to set IFS to null:
$ OLD_IFS=$IFS
$ IFS=
$ echo a b cd.txt| while read i
do
echo .$i.
done
. a b cd.txt .
Now if someone has embedded newlines in their filenames then that would be a
problem. At that point you're talking about 'xargs -0 (--null)', sort -z,
(--zero-terminated), using perl to chomp the newline and output a null
character, etc. How does 'svnlook changed' output filenames with embedded
newlines anyway?
do
grep -q $i $FILES_TO_REPORT_ON
Same for filenames that contain regex metacharacters.
The entries in the filelist svn property would need to be in a regex format.
So everything would be escaped already.
If not, then perl's quotemeta and greps --fixed-strings flags would be of use:
perl -ne 'chomp; print quotemeta($_) . \n' file.txt.
Anyway, IME, it's almost always a better idea to use the --xml option when
parsing svn commands, which implies writing a proper perl script. The work can
(probably) be done in bash, but with all the whitespace handling and
potentially multiple layers of interpolation going on, the code can get
unwieldy quickly.
Updated script:
#!/bin/bash
set -o pipefail
REPOS_PATH=$1
REV=$2
SVNLOOK_CMD=/path/to/svnlook
RECIPIENT_LIST=$($SVNLOOK_CMD propget ... my:email_list_prop)
if [[ -z $RECIPIENT_LIST ]] then
exit 0
fi
CHANGED_LIST=$(mktemp ...)
FILES_TO_REPORT_ON=$(mktemp ...)
$SVNLOOK_CMD changed ... | perl -ne 'chomp; print quotemeta($_) . \n'
$CHANGED_LIST || exit 1
perl -i -pe 's/^//' $CHANGED_LIST
perl -ne 'chomp; print quotemeta($1$2) . \n if
/^(trunk)\/|^(branches\/[^\/]*)\//' $CHANGED_LIST | sort -u | xargs -n 1 -i
svnlook propget $REPOS_PATH my:filelist_prop {} $FILES_TO_REPORT_ON ||
exit 1
cat $CHANGED_LIST | while read i
do
grep -q -F $i $FILES_TO_REPORT_ON
if [[ $? -eq 0 ]]
then
svnlook diff -r ... | sendmail -s $i was touched in an impure
manner $RECIPIENT_LIST
fi
done
RE: Help with post-commit script
-Original Message-
From: Alfred von Campe [mailto:alf...@von-campe.com]
Sent: Monday, December 02, 2013 3:44 PM
To: users@subversion.apache.org
Subject: Help with post-commit script
I need to implement a post-commit hook that does the following in a
standard Subversion repository (with trunk, branches, and tags at the top
level):
1. Checks for existence of a certain property in the top-level directory of
the trunk or branch
2. If property exists, check if any files listed in said property's value
has been modified
3. Send an email with all diffs from step 2 to the recipients listed in
another property
What makes it tricky is that in all steps above I need to be able to handle
trunk as well as any branches. In addition, since it is possible to submit
to both trunk and/or one or more branches in the same commit, and the
property may exist in one but not the other, I need to walk through all
files affected in the commit. I think this means I cannot use just svnlook
and will have to parse the output of svn log. My questions are:
1. Is parsing the output of svn log the best approach?
2. If not, what is a better approach?
3. I would prefer to write this in bash or perl, but would appreciate any
examples in other languages before I go re-inventing the wheel.
Thanks,
Alfred
P.S. Please CC me as I am not on the list.
1. Probably not.
2. Ssee below
3. See below
Pseudocode. You'll need to fill in the gaps, i.e. the ellipses. And you'll
probably want to delete the temp files with a trap (google on: bash delete temp
dir)
#!/bin/bash
set -o pipefail
REPOS_PATH=$1
REV=$2 # or is it the other way around?
RECIPIENT_LIST=$(svnlook propget ... my:email_list_prop)
if [[ -z $RECIPIENT_LIST ]]
then
exit 0
fi
CHANGED_LIST=$(mktemp ...)
FILES_TO_REPORT_ON=$(mktemp ...)
svnlook changed ... $CHANGED_LIST || exit 1
cat $CHANGED_LIST | sed 's/^//g' | perl -ne 'print $1$2\n if
/^(trunk)\/|^(branches\/[^\/]*)\//' | sort -u | xargs -n 1 -i svnlook propget
$REPOS_PATH my:filelist_prop {} $FILES_TO_REPORT_ON || exit 1
cat $CHANGED_LIST | while read i
do
grep -q $i $FILES_TO_REPORT_ON
if [[ $? -eq 0 ]]
then
sendmail -s $i was touched in an impure manner
$RECIPIENT_LIST svnlook diff -r ...
fi
done
Also, do NOT have any blank links in the my:filelist_prop. Or does that only
apply when using 'grep -v'?
RE: Branch/switch/merge question
From: Edward Ned Harvey (svn4) [mailto:s...@nedharvey.com] Sent: Tuesday, November 26, 2013 9:13 AM To: users@subversion.apache.org Subject: Branch/switch/merge question In particular, I branch (and switch) from /trunk to /branches/eharvey. I then make a few commits. I switch back to /trunk, and merge from the branch. I commit to trunk. (I'm always at a loss for comment, because I'm just committing things that have already been commented. But that's a side note.) I then switch back to /branches/eharvey, and merge from /trunk. So here's my question: Even if I'm the only person who committed anything... I was fully committed on /branches/eharvey, I then became fully committed on /trunk, and when I merge back into /branches/eharvey, suddenly I'm not fully committed. My latest status (check for modifications) shows the child subfolder as modified, and when I diff it, it's the svn:mergeinfo property that's different. It shows that I merged /trunk into /branches/eharvey, even though there were no changes from trunk to merge in. It's a feature. The repository HEAD revision changed, i.e. someone checked in somewhere else in the repository, so svn updates the svn:mergeinfo property anyway. Personally, I wish the merge and merge tools (especially mergeinfo) used the Last Changed Revision instead. So, most importantly, am I using svn branch/switch/merge in the way that it's intended to be used? Yes. Should my usage pattern be different somehow? No, but since you're the only one working on the trunk, you don't necessarily need to branch/merge. However, if you have a continuous integration server that's constantly building and deploying new commits from trunk, then working on the feature branch and only merging when your feature branch is stable is a good thing.
RE: Looking into using Subversion
From: vanderwalt.dev...@columbus.co.za [mailto:vanderwalt.dev...@columbus.co.za] Sent: Tuesday, November 19, 2013 1:47 AM To: Ben Reser Cc: Chris Shelton; Nico Kadel-Garcia; Subversion; bob.arc...@amsi.com; Andrew Reedick Subject: Re: Looking into using Subversion Thank you all, Chris Bob, Andrew, Ben. Bob, the Server I am taking about here is our development, not production server so it will be fine. Chris, Andrew, and Ben thank you for given me 3 solutions to explore. I think I am going to give Subversion try, only thing I am not too keen about is the command line interface. Our developers here would prefer a GUI client, any good ones you can suggest? The important thing is to use a 1.8.x client for the improved merging, i.e. not having to use the --reintegrate switch with 'svn merge' anymore. TorstiseSVN on Windows is great. Subclipse supports 1.8.x and works. However, last I checked, NetBeans requires you to set the subversion plugin to use the 1.8.x CLI instead of javahl or svnkit (which are limited to 1.7.) Again, last I checked, non-windows GUI clients also have the problem of being stuck at 1.7.x.
RE: svnmucc
-Original Message- From: Nico Kadel-Garcia [mailto:nka...@gmail.com] Sent: Monday, November 18, 2013 7:12 AM To: Vladislav Javadov Cc: Blair Zajac; Andreas Mohr; Geoff Rowell; users@subversion.apache.org Subject: Re: svnmucc Brother, unweaving the quotes is its own problem. You see, most filesystems allow single quotes and double quotes in the filenames themselves. Hilarity will ensue. On Sun, Nov 17, 2013 at 4:19 AM, Vladislav Javadov vapaam...@yandex.ru wrote: BZ The reason to support this syntax with command and arg on separate BZ lines is to support files with whitespaces in the names But what about quotes? Most OSes and programs accept quoted file names containing spaces. Single-line commands are more readable, IMHO. -- WBR, Vladislav Javadov And this is why I switched from bash to xash (aka xml bash). All my commands are now entered in xml format. Finally, no more -print0 and nested/escaped quotes nonsense! Example: cp -p foo bar Becomes commandargcp/argarg-p/argargfoo/argargbar/arg/command And multi-line commands and scripts go from: # Contrived example find . -type f -print0 | while read -d $'\0' i do sed 's/e/E/g' $i done | tee foo.txt 21 to: commands command argfind/arg arg./arg arg-type/arg argf/arg /command pipe/ command argwhile/arg argread/arg argi/arg /command command argdo/arg /command command argsed/arg arg's/e/E/g'/arg arg$i/arg /command command argdone/arg /command pipe/ tee stdout_format=human_ascii filefoo.txt/file /tee redirects redirectfile_no from=2 to=1//redirect /redirects /commands Simple and inherently accurate, natch?
RE: Looking into using Subversion
From: vanderwalt.dev...@columbus.co.za [mailto:vanderwalt.dev...@columbus.co.za] Sent: Monday, November 18, 2013 8:09 AM To: Nico Kadel-Garcia Cc: Subversion Subject: Re: Looking into using Subversion Thank for your response Nico. We what to debug from our development server. Not sure if there maybe is away to develop on the local PC, and check in the file into the repository (which will be on the Linux Server) which will copy it to the Tomcat's publish folder on the server? Use Jenkins (or other Continuous Integration software) to automatically deploy new commits to the server, and this would be out of the box functionality. Jenkins can be installed as a war, so you could drop it into Tomcat on your dev server as well. Process: Devs check into their own local workspaces. Jenkins polls subversion for new commits. Jenkins automatically deploys to the dev server when it sees the new commit.
RE: svn: E195016: merge error is dropping last character of path
-Original Message- From: Andrew Reedick Sent: Wednesday, September 11, 2013 9:19 AM To: users@subversion.apache.org Subject: svn: E195016: merge error is dropping last character of path So... any reason why the last character in paths are getting dropped in the Missing ranges: output? Ex: the k is missing from trunk in Missing ranges: portal/trunk Missing ranges: /portal/trun:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 Or, maybe the problem is limited to the first entry? Ex: the 'g' is getting left off in the first Missing ranges. portal/trunk/config Missing ranges: /portal/trunk/confi:4217,4378,4459 Missing ranges: /portal/trunk/config:4387,4435,4452 Just confirming that 1.8.4 has fixed the problem: * merge: fix path corruption during reintegration (r1523666) I re-ran my merge and the last letter is no longer being dropped from trunk and config, and that confi and config have been combined back into one line. portal/branches/dev.bug Missing ranges: /portal/trunk:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 portal/branches/dev.bug/config Missing ranges: /portal/trunk/config:4217,4378,4387,4435,4452,4459
RE: How to display the code in my branch without merge changes?
From: Gabriela Gibson [mailto:gabriela.gib...@gmail.com] Sent: Tuesday, October 15, 2013 7:24 AM To: users@subversion.apache.org Subject: How to display the code in my branch without merge changes? My goal is to get svn to show the current version of my code, without the merged changes added from trunk. I've tried a lot of different approaches by now (as advertised in svn help diff), but nothing seems to do the trick. thanks for any advice, Gabriela Create a new workspace and unmerge (aka reverse merge) the changes from trunk. Then diff the workspace. (You probably don't want to check-in the reverse merge changes.) Or Branch your code before the first trunk merge and cherry-pick merge your items to the new branch (i.e. don't merge over the trunk changes.) Obviously, if your code relies on, or otherwise interacts with the trunk changes, then you'll have to tweak your code (and will probably go with the new branch option.)
RE: How to display the code in my branch without merge changes?
-Original Message- From: Alfred Perlstein [mailto:bri...@mu.org] Sent: Tuesday, October 15, 2013 9:55 AM To: Gabriela Gibson; John Maher Cc: users@subversion.apache.org Subject: Re: How to display the code in my branch without merge changes? ...snip... If you are fully up to date with merges, then you should just be able to diff against trunk.That should show you the differences between your branch and the trunk (net changes). And if you aren't fully up to date, you can use a peg revision to limit trunk to the last merge, e.g. if r100 was the last merge to branch, and trunk is now at r999, then svn diff ^/trunk@100.
RE: Copy changes from one branch to another
-Original Message- From: Sven Richter [mailto:sver...@googlemail.com] Sent: Monday, September 30, 2013 8:29 AM To: users@subversion.apache.org Subject: Copy changes from one branch to another Hi, I have the following setup trunk branch A (created from trunk) | | | | | | Now, what I want to do is only commit my changes to the trunk and make sure that every committed change is replicated into branch A. This should be an automatic commit, triggered by the commit to trunk, while being aware of the fact that no other changes should be done in branch A but the autocommit from trunk. Another would-like requirement is that the commit metadata like author and commit time/date are kept, but this is not a must have. Is that possible with svn, maybe with autocommit hooks? If not, what other way would you see to achieve that? Post commit script that deletes branch A and then recreates branch A from trunk, i.e. make branch A effectively a tag. Since the delete and copy are server side commands, no workspace is needed to make it work. However this will fail if (when) you need to make custom changes on branch A.
RE: Copy changes from one branch to another
-Original Message- From: Sven Richter [mailto:sver...@googlemail.com] Sent: Monday, September 30, 2013 9:43 AM To: users@subversion.apache.org Subject: Re: Copy changes from one branch to another Hi, On Mon, Sep 30, 2013 at 3:14 PM, Andrew Reedick andrew.reed...@cbeyond.net wrote: Post commit script that deletes branch A and then recreates branch A from trunk, i.e. make branch A effectively a tag. Since the delete and copy are server side commands, no workspace is needed to make it work. However this will fail if (when) you need to make custom changes on branch A. But that has the effect that i will have all the changes from trunk in branch A, which is not what I want. I only want some certain changes inside there, the changes committed from our team. Go with Thorsten Schöning's svn:externals solution. If you can't use svn:externals then you'll most likely need to merge, which requires a workspace and runs the risk of merge conflicts, which tends to preclude automation. Either way, be careful that you're not trying to replace a complicated workflow/process with overly simplistic automation, i.e. don't replace merging or a formal delivery process with mindless automated commit replication.
Outlook macro for proper quoting (was RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?)
-Original Message- From: Geoff Field [mailto:geoff_fi...@aapl.com.au] Sent: Wednesday, September 25, 2013 7:27 PM To: Bert Huijben; 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? Hi Bert, From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Wednesday, 25 September 2013 21:04 PM To: Geoff Field; 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? I'll just reply in the html form as it will be very hard to convert this thread to plain ascii and I have better things to do than spending half an hour on that. As much as Outlook (and I know you're using Outlook because the headers of your message include X-Mailer: Microsoft Outlook 15.0) is a sub- optimal tool for traditional groups, it's not that hard to change the Format selection from HTML to Plain Text. The real problem/pain is that you then have to reformat the message to make sense in plain-text format. I haven't done much to this message and it's a bit of a mess. For those suffering from the embarrassment of posting with Outlook clients: QuoteFix Macro at http://sourceforge.net/apps/mediawiki/macros4outlook/index.php?title=QuoteFix_Macro#Configuration
RE: Shared branch vs single branch
From: C M [mailto:cmanalys...@gmail.com] Sent: Monday, September 23, 2013 4:05 PM To: Les Mikesell Cc: Bob Archer; Subversion Subject: Re: Shared branch vs single branch Unfortunately, we are lacking on processes and there's a definite lack of product management. But coming back to my original question: Are there any potential gotchas with using a single/shared branch? For now, that's the only change the team (and leadership) is looking to as the solution. Firstly, one branch only works if you only ever have one and only one development steam going at a time. This never happens because at a minimum, you need a branch to support production fixes, a branch for QA fixes for the final release candidate, and a branch for the next release, e.g.: * /branches/1.0.1 - prod bug fixes for 1.0.0 in prod * /branchs/1.1.0 - 1.1.0 is in its final round of QA testing, so only 1.1.0 bug fix work is accepted * /branches/trunk (aka 2.0 work) In other words, don't ignore, gloss over, or otherwise lie to yourselves over the need to support multiple branches and merging. Secondly, everyone will still require training. Multiple branches (see Firstly above) will require training for everyone. Even if you have the CM guy do the merges, you still need to teach the developers how to avoid creating Evil Twins (i.e. a particular Tree Conflict.) An Evil Twin is created when you 'svn add foo.java' on both the trunk and on the branch, instead of merging 'foo.java' from trunk to the branch. Thirdly, you need process and project management. If you can't track your work, even single branching is going to fail hard, such as when you have to back a feature out of trunk due to time constraints. If you can't identify/track the work back to individual check-ins, then you will have great difficulty in reverse merging a feature out of trunk and merging it to its own branch. If you can't assign work and/or manage requirements, then, technically, you cannot, in good faith, decide whether single or multiple branches are right for you. Fourthly, Semper Gumby; Always Flexible. Branching gives you flexibility. Going with single branching limits your ability to change, adapt to, or manage releases. If you have lousy requirements management, then single branching means you're more likely to wind up in death marches, late nights, and relying on full regression testing (which takes time that you won't have) to verify that you all haven't broken something stupid on trunk. If I had lousy/incomplete/late requirements then I would want to use feature branches to help mitigate the pain. Fifthly, keep your resume up to date. A good marriage counselor helps as well. Keep in contact with your company recruiter in case you experience higher than average developer burn out. Over-dramatic, but no process == inefficient work == making up the time with people's personal time, i.e. late hours, weekend work, etc.. To actually answer your question, the pitfalls of single branching are: a) people working on the same files will create conflicts during 'svn update'. However, svn locking can help reduce the pain. Dividing up the work so that folks are working on different parts of the software helps as well. Communication is key when multiple developers touch the same set of files. b) having to remove code. If a feature is unstable or cannot be completed in time, then you will need to reverse merge it out. Which can be more difficult with single branching over feature branching. Difficultly is increased the longer/bigger the release is, due to the increased chance of interdependencies with the removed feature. However, if you're doing Agile development (short release cycles/sprints, a small set of well defined requirements for each sprint, etc.) then the dirty trunk approach should work mostly easily. However, the longer your release cycle, the greater your chances of having to rip out a feature and the greater the difficulty it will be in doing so (due to dependencies, larger set of QA test to run through, etc..) Our developers code on a Unix like platform and have little SVN experience to boot. The idea of turning over merging to them seems to be a recipe for disaster. I would prefer to let the CM team handle the merges and figure out what I did incorrectly to mess up the previous merges. Go with the trained CM guy. Tree conflicts in Subversion aren't exactly well documented and require some experience to do correctly. However, your CM guy can't merge based on business logic, e.g. if something *shouldn't* be merged (such as a temporary hack) then you Someone(tm) needs to work with the Merge Meister, i.e. have a merge party. Good luck. It doesn't have to be perfect, but the more up front planning you do, the less of your life you lose to stress. Also, defining a process is the first step towards process improvement and a saner career. =) /soapbox off
RE: SVN merge attempting to reintegrate on a merge to a branch
-Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Monday, September 16, 2013 5:35 AM To: Andrew Reedick Cc: Goor, Stefan; users@subversion.apache.org Subject: Re: SVN merge attempting to reintegrate on a merge to a branch On Fri, Sep 13, 2013 at 04:16:17PM -0400, Andrew Reedick wrote: -Original Message- From: Goor, Stefan [mailto:sg...@thetasgroup.com] Is this a bug? Is it something we are doing wrong? Is there any information we could send that would help diagnose and prevent the issue? No idea. But I posted about the missing char issue a couple of days ago: http://svn.haxx.se/users/archive-2013-09/0116.shtml It's either a harmless presentation error, or the missing char implies a malformed pathname that is possibly mucking up the merge analysis? Hi Andrew, did you have time to answer Ivan's questions from this post? http://svn.haxx.se/users/archive-2013-09/0142.shtml Knowing where the mergeinfo corruption starts occurring would help us greatly with hunting down the issue. Does the corruption happen also if you use file:// URLs on the server during checkout/merge, instead of http:// ? This reply is a little late (jury duty) but svn:mergeinfo was clean (no truncations) on trunk and trunk/config for ^/..., working path, and directly on the server using file:///. Hopefully, http://svn.apache.org/r1523666 fixes the problem.
RE: SVN merge attempting to reintegrate on a merge to a branch
From: Goor, Stefan [mailto:sg...@thetasgroup.com] Sent: Friday, September 13, 2013 11:40 AM To: users@subversion.apache.org Subject: SVN merge attempting to reintegrate on a merge to a branch Recently when we attempted to merge a trunk project to a branch (in preparation of doing a merge of the branch back to trunk) we are got errors like the following: $ svn merge $SVNROOT/trunk/my_project . svn: E195016: Reintegrate can only be used if revisions 4401 through 4545 were previously merged from https://our.svn.servername/svn/branches/my_project/features/my_project_branch to the reintegrate source, but this is not the case: trunk/my_project Missing ranges: /trunk/my_project:4485 Missing ranges: /trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-4533 Since you sanitized your path names, is there any chance that the t in my_project is being left off on the first missing ranges line? E.g. trunk/my_project Missing ranges: /trunk/my_projec:4485 --- ** Missing 't' in 'my_project' ** Missing ranges: /trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-4533 When I encountered this, the solution was to either merge the branch to trunk (svn merge ^/.../my_project_branch), or to explicitly specify the revision range when merging up from trunk, e.g. svn merge -r 4401:4545 ^/trunk/my_project.
RE: SVN merge attempting to reintegrate on a merge to a branch
-Original Message- From: Goor, Stefan [mailto:sg...@thetasgroup.com] Sent: Friday, September 13, 2013 3:53 PM To: Andrew Reedick; users@subversion.apache.org Subject: Re: SVN merge attempting to reintegrate on a merge to a branch Hi Andrew, Thanks for your response. You are right, I hadn't noticed but on the first line about the missing ranges the last letter of the project name is missing and I had just pasted over it when I sanitized the path names. I got around this as you suggested by using the -r 4401:HEAD option but this is becoming a recurring problem for us lately. We prefer to merge the trunk project to the branch in preparation of reintegrating the branch to trunk but we seem to hit this issue quite a bit lately. Is this a bug? Is it something we are doing wrong? Is there any information we could send that would help diagnose and prevent the issue? No idea. But I posted about the missing char issue a couple of days ago: http://svn.haxx.se/users/archive-2013-09/0116.shtml It's either a harmless presentation error, or the missing char implies a malformed pathname that is possibly mucking up the merge analysis?
svn: E195016: merge error is dropping last character of path
So... any reason why the last character in paths are getting dropped in the Missing ranges: output? Ex: the k is missing from trunk in Missing ranges: portal/trunk Missing ranges: /portal/trun:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 Or, maybe the problem is limited to the first entry? Ex: the 'g' is getting left off in the first Missing ranges. portal/trunk/config Missing ranges: /portal/trunk/confi:4217,4378,4459 Missing ranges: /portal/trunk/config:4387,4435,4452 More importantly, if the first pathname is getting mangled, is it affecting how merges are resolved/calculated? Or is it just a presentation bug? This is 1.8.3 cygwin CLI client and in TortoiseSVN 1.8.1. == svn: E195016: Reintegrate can only be used if revisions 4109 through 4928 were previously merged from https://server/some/where/branches/foo to the reintegrate source, but this is not the case: portal/trunk Missing ranges: /portal/trun:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 portal/trunk/config Missing ranges: /portal/trunk/confi:4217,4378,4459 Missing ranges: /portal/trunk/config:4387,4435,4452 portal/trunk/doc Missing ranges: /portal/trunk/do:4378 portal/trunk/httpd-config Missing ranges: /portal/trunk/httpd-confi:4378 portal/trunk/private-certs Missing ranges: /portal/trunk/private-cert:4378 portal/trunk/schema Missing ranges: /portal/trunk/schem:4209,4217,4378 Missing ranges: /portal/trunk/schema:4209 portal/trunk/schema-newbase Missing ranges: /portal/trunk/schema-newbas:4217,4364,4378,4459 Missing ranges: /portal/trunk/schema-newbase:4241,4249-4250,4258-4261,4302,4354,4363-4364,4370,4377,4391,4420,4446-4450 portal/trunk/scripts Missing ranges: /portal/trunk/script:4147,4217,4378,4459 Missing ranges: /portal/trunk/scripts:4147,4236,4307,4371,4387,4390,4392,4459 portal/trunk/source Missing ranges: /portal/trunk/sourc:4125,4143,4145,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 Missing ranges: /portal/trunk/source:4114,4125,4135,4137,4143,4145,4150,4162-4163,4166,4168,4170,4186,4191-4194,4196-4199,4207-4209,4217,4219,4222,4225-4226,4228-4235,4237-4240,4243-4247,4252-4257,4265-4272,4274,4278-4279,4282,4285-4295,4300,4303-4306,4308-4328,4332-4335,4337-4343,4347-4348,4353,4355,4359,4364-4365,4367,4374-4376,4378,4383-4386,4388-4389,4394-4419,4421-4432,4434,4436-4437,4439,4441,-4445,4451,4455-4457,4462,4465-4467,4469 portal/trunk/source/includes/quotebuilder/changeorder_dealer_products_add.php Missing ranges: /portal/trunk/source/includes/quotebuilder/changeorder_dealer_products_add.ph:4125,4163,4217,4227,4378 portal/trunk/wsbin Missing ranges: /portal/trunk/wsbi:4277,4378 Missing ranges: /portal/trunk/wsbin:4273 Andrew Reedick CBeyond Cloud Development, SCM O: 678.486.8163
RE: How about a troubleshooting guide for tree conflicts?
-Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Friday, August 30, 2013 9:09 AM To: Vesa Paatero Cc: users@subversion.apache.org Subject: Re: How about a troubleshooting guide for tree conflicts? The SVN Book has a short chapter about tree conflicts which I wrote: http://svnbook.red-bean.com/en/1.7/svn.tour.treeconflicts.html However, it falls short of covering complex issues people actually run into in real life. How about we start with a list of the possible error messages? =) IME, a merge conflict means you, the user, have to manually recreate the tree via svn copy, svn mv, etc. commands. Which is a *huge* perception/paradigm change from how file merges are handled. Meaning, tree conflicts have zero automation/help from svn. Once you accept that, and learn how to read the messages, tree conflicts aren't that mysterious anymore.
RE: Feature Req: sorthand urls for branches/tags in CLI
-Original Message- From: Laszlo Kishalmi [mailto:lkisha...@ovi.com] Sent: Thursday, August 22, 2013 5:15 PM To: users@subversion.apache.org Subject: Feature Req: sorthand urls for branches/tags in CLI Implementation ideas: We put a specific property on project1 folder let's call it svn:branches for now. Here we could describe the layout of branches and tags for that part of repository. E.g.: a) Using prefixes: / /branches/ /tags/ b) Using some custom mapping/lists: trunk branches/* tags/* c) Using regexp captures: (trunk) branches/(\w+) tags/(\w+) Having this info, the path where this property is set, the name of the branch and the current path relative to wc root it is possible to construct a repository URL to be used. As far as I currently see there would be no change required on server side. Subversion doesn't have branches. I'd rather see branches as first class objects before we hack out a -b option. It's still an interesting idea, though. What happens when the svn:branches property gets merged or copied? It's an edge case, but it could cause an amusing amount of chaos if svn:branches gets copied around or merged unexpectedly. What is the behavior when you are in an externals? Do you respect the svn:branches in the externals, or do you work from the local repo's svn:branches, or neither? Overall, I'm not sure it would save a significant amount of typing. If you have a standard trunk/branches/tags repo structure, then you're not saving a lot by using -b foo in place of ^/branches/foo. Having to set 'svn:branches' for repos with non-standard trunk/branches/tags trees is a bit inconvenient and would discourage use.
RE: Switching
-Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Friday, August 23, 2013 1:34 PM To: Edwin Castro Cc: Subversion Subject: Re: Switching I can't, off the top of my head, think of a scenario where it would be harmful to replace an unversioned directory with a versioned instance, leaving any unversioned local files that happen to be there alone. Other than maybe the chance that you'd accidentally commit them later, but that is no different than if you had put the local files in after the switch. Am I missing something? Is there a way to --force that without also potentially --force'ing files that conflict to be clobbered? Dir permissions and ownership would change to that of the current user and umask and could create a security gap, but that probably falls under if you're using --force, it's on your head. How are symlinks handled by switch --force? It fails, or does it look at the target file/dir when deciding whether to replace it with a versioned object? How are hardlinks handled by switch --force? Is the hardlinked file removed and replaced with a brand new file? Or does switch --force work directly on the hardlinked file thus updating all the copies? On the windows side, would replacing a junction cause problems?
RE: how to simply : $svn update ?
From: Jay Vee [mailto:jvsr...@gmail.com] Sent: Friday, August 23, 2013 5:09 PM To: users@subversion.apache.org Subject: how to simply : $svn update ? I do '$svn status' and get that I am at a certain revision Type 'svn help' for usage. cpu:/dirsvn update At revision 32933. This leads me to believe that I am fully sync'd with the repo since it pulled nothing back. --- I do svn status and see something surprising cpu:/dirsvn status ? src/main ? src/test/java ? src/test/resources/META-INF means the above files are not added and do not exist in the remote repo (but yes they indeed exist there, If I do a fresh checkout, I see these directories there with many files. What's the output of 'svn update'? Is your workspace really pointed to where you think it's pointing? Run 'svn info' to verify the URL and revision numbers.
RE: Switching
-Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Thursday, August 22, 2013 12:21 PM To: users@subversion.apache.org Subject: Re: Switching How would you like Subversion to work in your case? From my understanding it breaks down to something generated some files for some reason in one of your branches and now you want to switch form that branch to another which does not contain the base directory of the generated files. What should subversion do with your generated files it doesn't know anything about? I don't see how this problem can be solved by any tool. Part of his frustration is that the files in question are listed in the global-ignores. So... maybe a feature request to have a 'svn switch' option to take global-ignores into consideration when deciding whether to keep or delete local files?
RE: Switching
-Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Thursday, August 22, 2013 1:34 PM To: Johan Corveleyn Cc: Thorsten Schöning; users@subversion.apache.org Subject: RE: Switching The problem isn't something in the way, the problem is something is there when nothing is expected. There is a directory in one branch but not the other. Subversion half empties it when switching to the branch without the directory. Then when switching back to the branch where the directory lives it complains that it can not add it because it is there. But that very same directory was part of the branch that is complaining that it can not add it because it is there. Okay, this isn't a svn issue. This sounds more like a I did a build against trunk, switched to branch B, and then did a build of B in a dirty workspace. That's just asking for trouble in terms of build accuracy and build repeatability; it's a bad practice in general. The whole trunk, switch to B, switch back to trunk directory conflict may be an annoyance, but a 'make clean' build option or cleanup script run after the switch sounds like something that you need to implement.
RE: Switching
From: John Maher [mailto:jo...@rotair.com]
Sent: Monday, August 19, 2013 1:31 PM
To: Subversion help
Subject: Switching
Hello,
I want to thank all who have been helpful. I have gotten my test project to
merge branches successfully. Now I am trying it on our production code and
wish to make sure I am not making any mistakes.
I use one folder for my source code (all branches) mainly because of vendor
requirements the code must be run from the same directory. I have created
two branches for two new features. One feature extends an existing library.
The other feature adds a new library as well as extending an existing one.
When I switch I create a conflict because the directory exists in one branch
and not the other:
That doesn't make sense. If you branched (i.e. created copies of a baseline)
then the dir trees should be identical. Extending/modifying the library
(adding new dirs) shouldn't create a conflict for svn switch, unless you
modified the same directory tree/structure in the workspace's branch and in the
branch you're switching too. This happens if you 'svn add' the same dir in
both branches. Example:
Bad, causes conflict:
svn add ^/branches/foo/new_dir
svn add ^/branches/bar/new_dir
Good:
Svn add ^/branches/foo/new_dir
cd to bar workspace; svn copy ^/branches/foo/new_dir .
It could also happen if you renamed/moved the same dir in both branches.
local unversioned, incoming add upon switch
This sounds like you have a normal, unversioned directory in the workspace. As
part of the switch, svn wants to add a versioned dir of the same name to your
workspace. You should be able to rename the local normal dir to a new name in
order to let the add operation be run unimpeded. I would 'svn revert -R' the
entire workspace[1], rename the normal, local dir, and re-run the switch. And
figure out why you have a normal, unversioned copy of the dir in the first
place.
This may or may not be what is supposed to happen, that would be the first
thing I would like to know. How to fix it would be the second thing that I
would like to know. According to the help of the resolve command says:
So I tried svn resolve -accept working LibraryDirectory but I believe that
was a mistake because then the directory was marked Delete which is not
what I wanted. Does anyone know what is the proper response?
Meh. Resolving tree conflicts is a bit of a manual process. IIRC, to resolve
it, you would need to
1) rename the normal, local dir, and
2) 'svn copy svn://server/.../LibraryDirectory .' Meaning, you need to manually
implement the add. ('svn switch' failed the add so you need to reproduce the
add manually.)
3) 'svn resolve' the dir.
Which is why I recommend just reverting[1] the switch, renaming the dir and
re-running the switch.
The main takeaway is that resolving tree conflicts isn't as easy as resolving
file conflicts. File conflicts let you use the 'mine-full', 'theirs-full',
etc. options, but tree conflicts do not. Fixing tree conflicts requires fixing
up the tree in the workspace yourself and then using 'svn resolve --accept
working' to tell subversion that the tree is now in the state you want. In
other words, you have to manually implement 'theirs-full'.
I did not want to lose the library from the working copy so I switched back
to the other branch and then switch back. Now it says:
local delete, incoming delete upon switch
You (or the failed 'svn switch' command) ran 'svn delete some_dir' in your
workspace. However, the current 'svn switch' also wants to run 'svn delete
some_dir'. So svn switch is complaining that it can't delete the dir because
it's already flagged for deletion. =/
It seems I did something wrong. My next step would be to add the library
back, but that may not be the best response. Any suggestions?
It sounds like you mangled the switch with too many hacks while trying to fix
it, i.e. the workspace is a mess. Just 'svn revert -R'[1], then 'svn status'
to make sure that there are no local/private files that could muck up the
switch.
The thing to remember is that svn is replaying changes on top of your
workspace. It walks the revisions, and for each revision, applies that
revision's changes to the workspace. So if you're applying 10 revisions' worth
of changes and the second revision breaks the switch/merge with a tree
conflict, then you have to manually fix the tree conflict (svn add, svn rm, svn
revert, etc.), resolve it, and then re-run the switch/merge to apply the
renaming 8 revisions.
[1] Before you run 'svn revert -R', run 'svn status' to make sure you don't
have any modified, uncommitted files that you really care about. Revert will
delete those changes.
RE: Switching
-Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Tuesday, August 20, 2013 1:33 PM To: Andrew Reedick; Subversion help Subject: RE: Switching Thanks for your reply. I agree it does not make sense. But it is reproducible. The dir trees are NOT identical because one branch has a library that the other does not. In normal use I would expect the branches to differ. And I assure you one of the branches does not have the directory causing the trouble, I checked on the server. So the branches are different and it appears impossible to switch between them without conflicts. For example, when I switch to branch P it switches OK. An svn status on the problem directory shows it with a '?'. Then I switch to branch E and get a conflict. It says local unversioned, incoming add upon switch. The local should be unversioned, it is not part of branch P. I do not know why the directory did not get deleted during the switch. An svn status shows the directory marked for deletion. So in one instance of time I get a message of a directory that is unversioned, incoming add, marked for deletion. When removing dirs, switch will not delete local/private/unversioned files. If there is a local file in a dir tree, then all the versioned files will be removed from your workspace, but a local tree will remain with the local files still in it. That's mostly likely why you see a '?' after the switch. Ex: 1. 'this_dir' exists in current workspace as a versioned dir tree. 2. 'this_dir' does NOT exist in branch P. 3. touch this_dir/hello_world.txt 3. svn switch ^/branches/P 4. svn status: ? this_dir The only file under this_dir will be hello_world.txt. All other versioned files/dirs will have been removed. Svn revert does not do anything useful. So I then issue svn resolve -- accept working UI_Email where UI_Email is the directory causing the problems. This clears the conflict. Then I switch to branch P. Then is says local delete, incoming delete. Why it has a local delete is beyond me. That folder is part of the branch, I want it there and never issued a delete. But subversion did. So I resolve this conflict the same as the last one and switch back to branch E. You guessed it, conflict again. You shot yourself in the foot. =) The local copy of the dir prevented switch from running the add. (Switch wasn't able to pull in the versioned copy of the dir.) Then you didn't fix the dir conflict by manually running 'svn copy' yourself to pull in the dir from branch P. When you did the resolve, you told svn that the current state of the dir is correct, and since the current state of the dir was effectively deleted, you wound up telling svn to delete the file from branch P. Again, when resolving tree conflicts, you need to manually copy/add/delete/mv manipulate the tree into the correct state before resolving the tree conflict. So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before). So now my code is gone. I delete the directory with supporting files. Then I switch to branch P. Success for now (I know failure is just a matter of time). You can recover the deleted versioned dirs and files via peg revisions. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.resurrect Then I switch to branch E. No conflict. But I won't get my hopes up yet, I still do not have the new library included which was the whole reason for creating the branch in the first place. Right. You deleted the dir from branch P. And you deleted the local/private files/tree as well. Thus no conflict with branch E. However, if you want to get the dir into branch E, then you should have merged from branch P to branch E (or used 'svn copy ^/branches/P/some_dir ^/branches/E/some_dir.) (But you'll need to restore the dir in branch P first via 'svn copy' and a peg revision.) So I copy over the directory and do a svn add then commit. Then I can switch to branch P. Argh. No, no, no. That creates evil twins. What you should have done was 'svn copy svn:///some_dir@1234 some_dir to add the dir back in. When you run 'svn add' you create brand new objects with no history. Evil twins break merging. This is where the problem arises. Subversion deletes the files but not the directory because it contains files that do not belong in subversion. I have no control over this as the compiler puts them there. They are on the global ignore list. Svn switch won't delete your local/private files because that would be rude, where rude equals destroying the user's files. So if you're switching, you need to manage private/local files. Maybe run 'make clean' (assuming you have a clean option) before switching? Or tweak your build script to put all build output in its own dir, instead
RE: Strange behavior
-Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Tuesday, August 13, 2013 9:40 AM To: Thorsten Schöning; users@subversion.apache.org Subject: RE: Strange behavior Hi Thorsten A good response to a less than good post. People could take lessons from you. Actually, its been a frustrating week. Sometimes subversion accepts the wrong slash in a path, other times it does not. Sometimes it enforces case sensitivity in a url other times it does not. Sounds like normal windows-unix interaction issues. They're not that bad if you have experience with UNIX systems. In the Windows CMD shell, if you wrap your pathnames in double quotes, you can use forward slashes instead of backslashes for directory separators, e.g. dir /s c:/program files/subversion, which helps when feeding paths between CMD commands and svn commands. Follow the book on how it instructs to import a project then it becomes impossible to merge and branch. That's odd. Very odd. It's much more likely that you're not grokking some paradigm or missed a step when creating the branch. You might want to post your branch/merge test process (especially the commands) and have the list vet it. And now for the second time I must discard my repository along with all the history I've accumulated. Yes you can say frustrating, bordering on maddening. Why? If you have a good initial import checked in, then create a new test branch, or even roll trunk back to the initial import. Example: Revision 10 of /trunk is your 200 commands to import the initial baseline. 1. Create a new test branch from rev 10: svn copy svn://server/trunk svn://server/branches/new_test_branch@10 Or if you want to roll trunk back to rev 10: 1. svn rm svn://server/trunk 2. svn copy svn://server/trunk@10 svn://server/trunk 3. create new test branch: svn copy svn://server/trunk svn://server/branches/new_test_branch The original trunk branch (with revisions 11+) is still available via peg revisions, but peg revisions are a topic for later. Or if you really want a fresh repo, then you can use 'svn export -r' to export the initial working baseline and then import those files into your new test repository. Meaning, if revision 10 represents your initial 200 commands of importing files, then export revision 10 using 'svn export -r 10 ...'. This lets you start a new repo without having to re-do the import from scratch. I would tell you about 'svnadmin dump', but given your current mental state, that's probably not a good idea. I got a good laugh from: Of course it can, just copy your 200 commands line by line one after another into a batch file. I know it was a humorous comment, but... Anyway, dealing with new software with new paradigms/assumptions can be very frustrating (e.g. going from ClearCase to 1.3 SVN, *g*) but you need to take a step back and relax. Importing and branching and merging in svn 1.8 really isn't (shouldn't be) that difficult. Plus, svn 1.8 is pretty robust and a mature product, so you shouldn't be fighting with it that much. Good luck, and keep up the perseverance. That which doesn't kill you, probably leaves you crippled and weak (or something to that effect.)
RE: Strange behavior
-Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Monday, August 12, 2013 10:18 AM To: Ryan Schmidt Cc: Subversion Users Subject: RE: Strange behavior Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me. You're overthinking this. You can use OS level commands to trim down the files to import. Copy the files to a temp directory, delete the files you don't want imported, and then run 'svn import' on the tmp dir. Even if you have mistakes in the import, you can use 'svn rm' and 'svn add' to clean things up. It would be nice if you could pass 'svn import' a list of filenames/regexes to include or exclude, but modern shells already have the tools to filter and delete files, so there's little need to add those wheels to 'svn import'. Especially since the import is normally a one-time event. Are you using 'svn import' multiple times? (Such as to create additional branches of the code?) If so, that would be bad, as in wrong paradigm/workflow. As for branching, here's the short version for the 1.8 svn client: 0) Use 'svn import' to create the initial baseline, say /trunk. then 1) Create the branch: 'svn copy svn:/server/trunk svn:/server/branches/foo.2.0.0' 2) Create branch workspace: cd /myworkspaces svn co svn:/server/branches/foo.2.0.0' cd foo.2.0.0 3) Work on foo.2.0.0 3.1) 'svn add' to add new files (svn:ignore will help here.) 3.2) 'svn ci' to commit the files 3.2) Periodically merge trunk changes up to foo.2.0.0: svn merge ^/trunk Note: makes sure your foo.2.0.0 changes are checked in before merging up from trunk, 'svn status' When foo.2.0.0 is done, first merge trunk up to foo.2.0.0 to make sure that foo.2.0.0 has the current trunk changes 4) 'svn merge ^/trunk' 4.1) Resolve any conflicts. Now merge foo.2.0.0 down to trunk. 5) Create a clean merge workspace cd /myworkspaces 'svn co svn:/server/trunk' cd trunk Note: if you are reusing a workspace, then 'svn status' and 'svn update' to make sure it's clean and ready for a merge. 6) 'svn merge ^/branches/foo.2.0.0' 6.1) Resolve any conflicts. 7) 'svn ci'
RE: Strange behavior
-Original Message-
From: John Maher [mailto:jo...@rotair.com]
Sent: Monday, August 12, 2013 3:27 PM
To: Bob Archer; Edwin Castro; users@subversion.apache.org
Subject: RE: Strange behavior
Thanks Bob, that may be exactly what I am looking for. Something that
would affect all the files without having to issue over 200 commands or
build a dummy directory just for importing. Although that second
suggestion provided by Andrew is definitely better than the first.
I couldn't find where it discusses the global config in the book, if it
does at all. And even if it does I doubt it would help because it
won't tell me where to find the file. Unless there is a command to
edit it. I tried a search and someone says there is a site-wide config
(what I need) and a user config but not where they are. I am using
Windows XP and an having a difficult time finding this file.
I can't even find the name of it. If someone can provide that I could
at least search for it and hope it has some clue inside as how to alter
it.
Plan B might be to use svn_load_dirs.pl:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
It has a glob_ignores option, or will try to read your global-ignores from
your local svn config file.
From the script:
===
# If no glob_ignores specified, try to deduce from config file,
# or use the default below.
my $ignores_str =
'*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
if ( defined $opt_glob_ignores)
{
$ignores_str = $opt_glob_ignores;
}
elsif ( -f $ENV{HOME}/.subversion/config )
{
open my $conf, $ENV{HOME}/.subversion/config;
while ($conf)
{
if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
{
$ignores_str = $1;
last;
}
}
}
svn add failing with svn: E200009: Can't set 'svn:eol-style': ... has binary mime type property and/or inconsistent newlines
svn add is having trouble with *.png files. This is with a 1.8 and a 1.7.9 client. I create a new test repository, copy in some vender code, then when I run svn add I get the following error on 1.8: svn add build-pipeline-plugin-1.3.3 ... A build-pipeline-plugin-1.3.3\src\main\resources\index.jelly A build-pipeline-plugin-1.3.3\src\main\webapp A build-pipeline-plugin-1.3.3\src\main\webapp\images svn: E29: Can't set 'svn:eol-style': file 'C:\temp\1.8\test18\tags\build-pipeline-plugin-1.3.3\src\main\webapp\images\gear.png' has binary mime type property When I revert and re-run the add, the add will sometimes fail on a different *.png file, which is odd. Under 1.7.9, I get one of two errors, either: svn: E29: File 'C:\temp\test18\build-pipeline-plugin-1.3.3\src\main\webapp\images\application-small-list-blue.png' has binary mime type property or svn: E29: File 'C:\temp\test18\build-pipeline-plugin-1.3.3\src\main\webapp\css\redmond\images\ui-icons_f9bd01_256x240.png' has inconsistent newlines svn: E135000: Inconsistent line ending style This is on Windows 7 32-bit with svn, version 1.7.9 (r1462340) or svn, version 1.8.0 (r1490375) clients from Collabnet. 'svn import' imports the files without issue. Enabling auto-props and uncommenting the '*.png' auto-prop in the client's config file made no difference either. Anyone have any ideas? Steps to reproduce: Create a new repo: 1. cd c:\repos 2. svnadmin create test18 3. svnserve -d -r c:\repos 4. edit test18\conf\svnserve.conf set anon-access = write in the [General] section Create a new workspace: 5. cd c:\temp\ 6. svn co svn://localhost/test18 7. cd test18 Get the files: 8. unzip build-pipeline-plugin-1.3.3.zip Zip is available here: https://docs.google.com/file/d/0B-xhQuXzTnK8VnJmNS1KX2NmZDg/edit?usp=sharing Or you can install a Mercurial (Hg) client and hg clone https://code.google.com/p/build-pipeline-plugin/ build-pipeline-plugin-1.3.3 cd build-pipeline-plugin-1.3.3 hg co build-pipeline-plugin-1.3.3 rd /s/q .hg del .hgignore .hgtags cd .. xcopy /s/e/v/i build-pipeline-plugin-1.3.3 test18/build-pipeline-plugin-1.3.3 Run the add: 9. svn add build-pipeline-plugin-1.3.3 10. Extra credit, revert and run again to see it fail on different files: svn revert -R build-pipeline-plugin-1.3.3 svn add build-pipeline-plugin-1.3.3
RE: svn add failing with svn: E200009: Can't set 'svn:eol-style': ... has binary mime type property and/or inconsistent newlines
-Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Tuesday, July 09, 2013 1:22 PM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: svn add failing with svn: E29: Can't set 'svn:eol- style': ... has binary mime type property and/or inconsistent newlines Can you try setting *.png = in the auto-props section? Perhaps your registry has a setting that that will override. That said, perhaps your registry has a setting for *.pn* which that will _not_ override; so check your registry: REGISTRY:HKLM\\Software\\Tigris.org\\Subversion\\Config REGISTRY:HKCU\\Software\\Tigris.org\\Subversion\\Config For the archives, if this hadn't been a new repository, I'd have suggested to look for inherited svn:auto-props properties too: % svn pg --show-inherited-props -R svn:auto-props No joy. Setting *.png and enabling auto-props didn't work. The registry has no property settings (for both Tigris.org and Collabnet). And svn pg --show-inherited-props -R svn:auto-props returns nothing. However 'svn add --no-auto-props' does allow the add to work, but that's a bit drastic and inconvenient. That fact that 'svn add' fails on different files is really throwing me for a loop. I'm beginning to wonder if Something(tm) is borked with my workstation (anti-virus, some left-over DLL in the path, etc.)
RE: svn add failing with svn: E200009: Can't set 'svn:eol-style': ... has binary mime type property and/or inconsistent newlines
-Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Tuesday, July 09, 2013 2:00 PM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: svn add failing with svn: E29: Can't set 'svn:eol- style': ... has binary mime type property and/or inconsistent newlines Andrew Reedick wrote on Tue, Jul 09, 2013 at 13:40:53 -0400: However 'svn add --no-auto-props' does allow the add to work, but that's a bit drastic and inconvenient. That fact that 'svn add' fails on different files is really throwing me for a loop. I'm beginning to wonder if Something(tm) is borked with my workstation (anti-virus, some left-over DLL in the path, etc.) Most likely you have an [auto-props] setting somewhere that's getting picked up. Bingo. Somewhere was the operative word. The Collabnet config file was being read from my roaming profile instead of from my windows home dir. The roaming copy of config had * = svn:eol-style=LF, and that auto-prop seems to have been causing the breakage. (global-ignores = *.* * is a great way to narrow down what config file is being read.) And the reason why 'svn add' was failing on different files is because 'svn add' walks the directory tree in a different order each time. Thanks for the help! Now I must find a wall to quietly beat my head against.
RE: svn add failing with svn: E200009: Can't set 'svn:eol-style': ... has binary mime type property and/or inconsistent newlines
-Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: Tuesday, July 09, 2013 3:12 PM To: users@subversion.apache.org Subject: Re: svn add failing with svn: E29: Can't set 'svn:eol- style': ... has binary mime type property and/or inconsistent newlines On 09.07.2013 20:33, Andrew Reedick wrote: Bingo. Somewhere was the operative word. The Collabnet config file was being read from my roaming profile instead of from my windows home dir. You're aware that, on Windows, Subversion doesn't look for config files in %USERPROFILE%\.subversion at all but in %APPDATA%\Subversion? I'm aware now. (I've been using a Cygwin svn client for some time now, which reads from ~/.subversion.) The real question is why I had a %USERPROFILE%\.subversion tree in the first place (timestamps are from January.) *shrug*
1.8 commit failed - nothing in the error logs
I just had a commit fail midway on three different 1.8 clients without any kind of error logged in the output, in the client's Event Viewer (Win7,) or on the repo server's httpd logs (linux.) No dump file either. Starting with a fresh checkout made no difference. There's no pre-commit hook. I have used 1.8 to do merges and commits previously. The commit did work with a 1.7.9 client (collabnet on win7 in a fresh workspace.) 1. Does anyone have any more ideas on where I can check for additional error logging? (on Win7, Cygwin clients, and Apache on a linux repo server.) 2. Has anyone seen this behavior before in 1.8? My google-fu found nothing. This was with three clients, svn, version 1.8.0 (r1490375) for all three: Cygwin svn client, TortoiseSVN, and CollabNet's client in a CMD window. Server is at 1.6.18 (r1303927) (CollabNet) over https. I was adding a vendor branch manually: 1. svn copy ^/branches/build-pipeline-plugin-3.3 build-pipeline-plugin-1.3.4.1 2. cd build-pipeline-plugin-1.3.4.1 3. rm -rf; rm -rf .* (OS delete) 4. Extract the build-pipeline-plugin-1.3.4.1.tar.gz into the now empty dir 5. svn status | grep '^?' | sed 's/^?//' | xargs svn add (To add any new files.) 6. svn status | grep '^!' | sed 's/^!//' | xargs svn rm(To delete any removed files.) 7. svn ci -m 'Added 1.3.4.1 from https://github.com/jenkinsci/build-pipeline-plugin/releases/build-pipeline-plugin-1.3.4.1' (or use TortoiseSVN's SVN Commit) After each failed commit, 'svn cleanup' was required since everything was still locked. On both the cygwin client and collabnet windows client, the check-in just stopped midway at the same point without any message. The exit code was set to 1 however. $ svn ci -m 'Added 1.3.4.1 from https://github.com/jenkinsci/build-pipeline-plugin/releases/build-pipeline-plugin-1.3.4.1' Adding . Deleting .hgignore Deleting .hgtags Deleting .pmd Adding README.md Sendingpom.xml Sending src/main/groovy/au/com/centrumsystems/hudson/plugin/buildpipeline/BuildJSONBuilder.groovy Sending src/main/groovy/au/com/centrumsystems/hudson/plugin/buildpipeline/ProjectJSONBuilder.groovy Sending src/main/java/au/com/centrumsystems/hudson/plugin/buildpipeline/BuildForm.java Adding src/main/java/au/com/centrumsystems/hudson/plugin/buildpipeline/BuildGrid.java $ The TortoiseSVN client did create an error report, but I think it just means that TortoiseSVN is blocked (firewalled) from connecting to its error reporting server. Plus the 1.7 client commit worked, and I have used the cygwin 1.8 client to do merges and commits previously, so it can't be a permissions issue. --- SendRpt: Error --- Error 403 fault: SOAP-ENV:Server[no subcode] HTTP/1.1 403 Forbidden Detail: HTTP/1.1 403 Forbidden Content-Type: text/html Server: Zscaler/4.1 Cache-Control: no-cache Content-length: 3649 HTTP/1.1 403 Forbidden Content-Type: text/html Server: Zscaler/4.1 Cache-Control: no-cache Content-length: 3649 HTTP/1.1 403 Forbidden Content-Type: text/html Server: Zscaler/4.1 Cache-Control: no-cache Content-length: 3649 ... snip ...
RE: Question about subversion
From: Marc Davenne [mailto:marc.dave...@cramif.cnamts.fr] Sent: Wednesday, June 26, 2013 10:37 AM To: users@subversion.apache.org Subject: Question about subversion Hi there. I have a question about subversion. I have a theory on what files should not be on SVN and I would like you to tell me if you agree. If you dont agree can you tell me why please. If you see more files that should not be there, tell me and why. Files who should not be on SVN : * files automatically generated * files containing specific information about my development environment (so properties files for example) * executable files PS: I am conscious that we can put anything to subversion but I am looking for Best practices Thank you so much Wrong question. The correct question is: Do I have what I need to reproduce the build? Generally speaking: * The reasons to avoid checking in generated files are: - they can be re-created automatically, - checking them in results in duplicate data which - takes up space unnecessarily - leads to data synchronization issues, i.e. are the generated files I checked in, the same as the files the build generates? And before you say that's a stupid thing to worry about, ask yourself what happens when a checked in generated file is no longer generated by the build? (Someone will have to manually delete the no longer needed generated file from the repo.) * The reason to avoid checking in dev environment files is because they're different between everyone's work environment and provide no value to the build process. * The reasons to avoid checking in executable files are: - they're big - they can't be merged, and/or - the executable is generated by the build and thus can be re-built from code if necessary. However, as others have noted, there are times when you want to check in such files. They're guidelines, not hard and fast rules. Guidelines/Rules exist to support your goals. Your goals are build reproducibility, accurate deployments, and other SCM-ish things that allow your organization to deliver a product that customers will pay money for so that your company can pay your salary. Craft your guidelines/rules in that context and you'll be fine.
RE: History in subversion
From: Olivier Antoine [mailto:oliviera201...@gmail.com] Sent: Thursday, June 13, 2013 3:57 PM To: users@subversion.apache.org Subject: Re: History in subversion Thanks All again for your help, If you're just trying to find a file in the current version of the repo, then svn ls -R svn://... You can use '-r' and peg revisions to search older revisions of the repo tree. Yes, I started a short perl script for this, but this is strange that nobody asked for a svn+find command (IMO). Because in SVN, you're normally working in a workspace and not directly in the repository. 'svn log' is your 'ct find' in most cases. Plus, in SVN you're working in a workspace most of the time and the normal command line tools (e.g. find, dir /s) work just fine, so there's not much need to re-create the wheel with SVN equivalent commands. You need 'ct find' because all the history is tracked in each individual element, whereas in SVN, history is contained in each (global) revision. In other words, you're probably trying to apply CC paradigms to SVN. Tree conflicts seem to be very mysterious. Why is there a such issue in SVN and not CC - what to think about this, please ? Directory merging wasn't in the initial design architecture of SVN... It's been added in bits since 1.4(?) and hasn't really gotten good until 1.6/1.7. And of course : Is it possible to do refactoring on any branch, and to merge to any branch without trouble ? Mostly. Again you have to deal with the limitations of 'merge --reintegrate' in 1.7.x (which goes away in 1.8.) If you are merging unrelated code (i.e. no common ancestor) then you're asking if SVN can merge Evil Twins. I think the answer is mostly yes, but I could be wrong because it's rare that I encounter that situation. Ideally, your branches have a common ancestry in order to make merge conflict resolution easier. You can ignore ancestry to merge unrelated trees, but if you find yourself merging often between unrelated (i.e. no common ancestor) branches, then I would hazard to say that there's something wrong with your branching process and/or baseline management (i.e. barring an exceptional use case, you might be using SVN incorrectly or working against SVN's branching paradigm?) Like I said above, I wish to continue : - to create tags on branch (and to keep the link of the tag with the branch) - and to create a branch from a tag (and to keep the information that the branch starts from this tag). These are raisonnable SCM principles, don't you think ? SVN does that. But instead of applying labels to each element, svn simply makes a complete copy (i.e. cp -pr branch1.0 tags/REL_1.0). In CC terms, it's conceptually similar to adding '-mkbranch REL1.0' to a config_spec and doing a checkout/checkin on each element to create the REL1.0 branch. And then locking the REL1.0 branch so folks don't check into it. (But SVN's branching/tagging is very efficient and fast.) You can get the link back to the branch point via 'svn log --stop-on-copy -v -r 1:HEAD -l 1'. (But there is an edge case which breaks that, requiring iterative use of 'svn log --stop-on-copy'. *grumble*) I think that dynamic view is still a nice concept. Dynamic views is something that users like much, and they desespair when they have to migrate to snapshot views. You create your view, you have an (almost) real-time connection to the repository, your view is available immediatly on all the machines. The working copy needs to be loaded, recreated and reloaded on each machine. Back in my day, CC snapshot views were terrible/horrible/nearly_unusable. SVN workspaces are simply great. I doubt your users will complain once they start using them. IME, the only downside to SVN workspaces/snapshots is that developers will whine about having to checkout a full directory tree no matter how small the tree. 'svn switch' helps reduce the need to checkout full workspaces, but it still doesn't reduce the whining though. :( But I never saw another tool with these principles : real-time access to repository, build based on version (not on time), winkin, configuration audit, SCM process level (stream, baseline, component), multisite. Yes, but in practice, you don't really need real time access to a repository. In SVN, you do your work, then when you're ready, you run 'svn update' to pull in other people's changes. Meaning, you decide when to take changes instead of having random changes spontaneously appear in your view. It helps to remember that SVN was designed to support open source projects with developers spread across the world. It's why hooks are server side only (instead of client side hooks,) why workspaces are snapshots instead of dynamic views, why svn URLs are URLs, etc.
RE: History in subversion
From: Olivier Antoine [mailto:oliviera201...@gmail.com] Sent: Wednesday, June 12, 2013 3:42 PM To: users@subversion.apache.org Subject: Re: History in subversion Thanks All for your help and advices, But : With CC, I can easily search for any file element in a repository, and directly get its path, With SVN, I have to check all revisions, then I can know where this element is located in the repository (maybe several locations), I can find in which revision it was removed. This is double manual search. You cannot directly diff two revisions of a directory, where diff is defined as diff'ing the list of file/dir objects in the directory. Instead, SVN will diff the files under the directory tree. From a CC point of view, svn file objects are first class objects with version a version tree, history, etc., whereas SVN directory objects are not. (SVN dirs are second class-ish.) This should help you to find files and what rev they're in. '^/' is the path or svn url to check. Foo.java is the file or regex you're looking for. svn log -v -q ^/ | perl -ne '$r=$_ if /^r\d+/; print $r, $_ if /foo.java/;' When users ask for help, I have to go in their repository that I don't know at all, users often give less than half the information I need to locate the file where they need help. With CC, I can quickly analyze a repository, and get easily the missing information. With SVN, I feel like blind, because I cannot do the same analysis on the repository. I cannot do a global search, I have to check the revisions individually. If you're just trying to find a file in the current version of the repo, then svn ls -R svn://... You can use '-r' and peg revisions to search older revisions of the repo tree. About peg revision : Peg revision means that I can access any file and directory version without checkout, this is already a nice help. But : is there also an individual identifier for directory and file (uuid, oid, ..) ? There's no such thing as a uuid or oid in SVN (or at least one that is user visible.) Instead, you can use svn_url + revision number or svn_url + 'Last Changed Rev' (which can be found via 'svn info') in order to uniquely identify a particular revision of something. 'Last Changed Rev' is preferable. However, since SVN doesn't have true renames, 'svn copy' will normally create a new object with a new revision (aka last changed rev) number. A new revision number won't be created if you copy the parent dir the file is in. In CC parlance, instead of /repo/branches/1.0/foo.java and /repo/trunk/foo.java just being hard links to revision object #1452134521, in svn you wind up with either a new revision number: 1. svn copy /repo/trunk/foo.java /repo/branches/1.0/foo.java 2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java ... Last Changed Rev: 100 ... Last Changed Rev: 123 Or if you copy the parent dir, foo.java's rev number remains unchanged: 1. svn copy /repo/trunk /repo/branches/1.0 2. svn info /repo/trunk/foo.java /repo/branches/1.0/foo.java ... Last Changed Rev: 100 ... Last Changed Rev: 100 So technically yes, SVN has the Evil Twin problem, however, it doesn't really cause problems with file merges per se, so Evil Twins aren't really a problem. Directory tree merges on the other hand, can be murder, but tree conflicts have been greatly improved in 1.7. Could you help more on diff dirs, please : - What is the best way with SVN to compare a same directory on two different branches ? 'svn diff', or checkout/export both branches (directories) and run your favorite diff tool on them. If you want to diff the contents of the dirs (i.e. the hard links,) then you can try 'svn ls -v' and diff the output (look at the rev numbers.) Generally speaking, in SVN, you don't diff directories, you diff the files in the baselines (aka branches.) However, since SVN revisions are changesets (a collection of related changes,) you can also use 'svn mergeinfo' to diff two baselines/branches/directories (i.e. find what changes have not been applied from branchA to branchB.) Or you can just run the merge command to see what would get merged and then 'svn revert -R' to get back to a clean workspace (instead of checking in.) You can even do a a 'svn merge --ignore-ancestry' to merge unrelated trees (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata) Long story short, if you are managing changesets between branches, then svn is quite adequate. If you're diffing code trees, then something has gone wrong with your merges and/or change management process. =) I am very confused by many things with SVN, one of them is : - I can merge from any directory to any directory anywhere, and I just get a terrible Tree conflict. With CC, the merge is inside the version tree of the file or directory element.
RE: History in subversion
From: Olivier Antoine [mailto:oliviera201...@gmail.com] Sent: Tuesday, June 11, 2013 4:45 PM To: users@subversion.apache.org Subject: Re: History in subversion Thanks for your help, I will try again this. But this is very poor compared to ClearCase. Nobody tried to script that ? I used to use ClearCase in a past life (3.0 - 6.0). I haven't missed the ability to diff dirs. You might be stuck on doing things the CC way instead of learning the Subversion paradigms. It's going to be frustrating for a little while (it was for me.) What are you trying to do that requires diff'ing the contents of directories? It is also possible to read the SVN repository without checkout, there is a way to address an element, something like this : element url@revnumber But it is not possible to use a syntax like this : directory@revnumber/file You want to read up on peg revisions: http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html You don't need to specify the rev for each path in the component, e.g. /view/foo/path@1/foo@2/bar@3/j.java@5. In SVN, the rev number is global, so you just /path/foo/bar/j.java@5. I tried, it doesn't work. Actually, I just try to analyze all elements, files and directories, contained in a SVN repository. I'd like to be able to parse all the elements - if possible without any checkout (that would be great). Use svn export (or for individual files, svn cat) Other challenge is : I need to restore a file element that has been removed in a very old revision, and of course I don't know which one. Any search command or script with Subversion ? You'll need to use a peg revision, e.g. svn copy svn:///path/foo.java@1234 . To find the revision that the file was in can be tricky if you have deleted a parent dir. In the average case, you can run svn log -v -q ^/path/to/branch log.txt. Then search the text file for your missing file to get the revision. You can also use svn log -v -q | egrep '^r|\/foo.java'. Worse case (you deleted a parent dir), you'll need to run the 'svn log' against the root of the repository (svn log -v -q ^/). To re-emphasize, I'm very serious about the need to stop trying to apply CC paradigms to SVN. It's frustrating, and, in my experience, the CC way of doing things didn't provide significant advantages in (or over) SVN.
RE: Tree conflict on Fresh checkout
From: James Hanley [mailto:jhan...@dgtlrift.com] Sent: Tuesday, June 04, 2013 1:44 PM To: users@subversion.apache.org Subject: Tree conflict on Fresh checkout We are seeing a strange anomaly after our last check-in - on fresh checkout there is a tree conflict into a new path - I've included the output below. $ svn status D C Project/settings/MkImage local unversioned, incoming add upon update D Project/settings/MkImage/Makefile D Project/settings/MkImage/defs.h D Project/settings/MkImage/main.c Summary of conflicts: Tree conflicts: 1 Any chance it's a case issue, i.e. MkImage versus mkimage in the same dir? Do an 'svn ls Project/settings'. And are you using a Windows svn client in a cygwin bash shell, or the cygwin built svn client?
RE: Tree conflict on Fresh checkout
From: James Hanley [mailto:jhan...@dgtlrift.com] Sent: Tuesday, June 04, 2013 3:12 PM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: Tree conflict on Fresh checkout I can reproduce on the versions specified above of the CygWin svn client within CygWin, but I haven't tried the native windows svn client. Strange thing is that this is only an issue with MkImage, and MkSharedData... user_dude@computer_node ~/projects/my_project/my_project_03b_pristine $ svn ls -v Project/settings 2528 cm_user May 30 19:28 ./ ... 2528 cm_user May 30 19:28 MkBinFile/ 2528 cm_user May 30 19:28 MkImage/ 2528 cm_user64131 May 30 19:28 MkImage.exe 2528 cm_user May 30 19:28 MkSharedData/ 2528 cm_user59528 May 30 19:28 MkSharedData.exe ... 2209 cm_user 85 May 07 12:52 run.cmd user_dude@computer_node ~/projects/my_project/my_project_03b_pristine $ 'svn ls' sorts output and the sort is case sensitive. Since you truncated your output, we can't tell if you have a case sensitive filename problem. Run 'svn ls -v Project/settings | grep -i mkimage' to see if you have duplicate mkimage entries. Under 1.7.9, I get a tree conflict when I have alpha and Alpha in the same dir under Cygwin. $ svn ls -v svn://localhost/test/case 111 test Jun 04 15:18 ./ 111 test Jun 04 15:18 Alpha/ 110 test Jun 04 15:18 alpha/ $ svn co svn://localhost/test/case Acase/Alpha C case/alpha Checked out revision 111. $ svn status case D C case/alpha local unversioned, incoming add upon update Summary of conflicts: Tree conflicts: 1 Finally, if you're using Outlook, when composing an email for the list, click Options - Plain Text.
RE: Merging change sets for a production release,
-Original Message- From: Gavin Baumanis [mailto:gbauma...@cogstate.com] Sent: Monday, June 03, 2013 12:31 AM To: users@subversion.apache.org Subject: Merging change sets for a production release, Importance: High At the moment we do all of our work on /trunk and also have /branches/releases/1.0 When we have enough issues, we mark the ready / required issues with a new release milestone and I go about the task of merging the required changes from trunk to the release branch. Is there a reason why you all are not doing Release Planning ahead of time? Here is what I am currently doing, that is giving me some issues, and I am hoping someone might be able to see what I am doing wrong / have some advice / comments to better the process I am using. Let's assume that I have multiple completed issues ready to merge from trunk that will become the Changes from the last version. Let's also assume that I have multiple subversion commits per issue - sometimes ~20 commits can be assigned against an issue. Let's also assume that the very same files that have the required changes to go to the new release - have other, not-ready for release changes made to them too. The scenario seems pretty ordinary to me - but I could, of course, be completely wrong. Anyway, So I open the first issue, notice there are 3 commits assigned to this issue. The first commit has 3 files, I do a cherry pick merge from trunk for each of the individual files listed in the issue. (Ignoring the paths...) svn merge -c 1234 /trunk/myPath/myFile1.c /branches/release/myPath/myFile1.c svn merge -c 1234 /trunk/myPath/myFile2.c /branches/release/myPath/myFile2.c svn merge -c 1234 /trunk/myPath/myFile3.c /branches/release/myPath/myFile3.c I manually resolve any conflicts that I may have. I then open the 2nd issue and repeat the process above as required for the change sets listed in the 2nd issue. Is each svn commit tied to an issue? Meaning, are all the changes in a single revision tied to an issue? You shouldn't need to merge individual files. Just do a 'svn merge -c 100,110,...,N svn_url' and let svn walk through the cherry-picked merges. A problem I am having is that I tend to get a lot of Merge conflicts doing it this way. But my biggest problem and the purpose for this email is; I might have a quite a few helpdesk issues to create a new release from. The same file might be edited in numerous issues. I often find myself doing a merge of a revision number less than one I have already performed. (depending on the order that I do the issue merging, of course) And oddly to me - I find at times when this is the case that my initial merge to the release branch is negated / overwritten. I am certain that it is a usage issue - but short of somehow ensuring that I do all the required merges in order - which is simply just too difficult to achieve - I find myself constantly battling with ensuring that the release branch is updated with all that this is necessary. If anyone has any ideas I would be most grateful. Change your process. Brick Wall Analogy: Imagine that trunk is a brick wall built with 100 bricks (issues.) You're only merging 80 bricks (completed issues) to the release branch. The 20 missing bricks can result in gaps in your wall that are structurally unsound, or could even result in bricks floating in mid-air due to dependency issues (supporting bricks/issues were not merged over.) It's a crazy, slow, and stressful way to build a wall. IMO, you have several problems: 1) A lack of release planning. You all don't decide on what's going into a release until after the work is done. Which means you don't take dependencies into account. You don't take development time into account which can result in continual merge conflicts since you are always having to skip over commits related to the long running work-in-progress issue. You wind up mixing an inordinate amount of complete and incomplete code together which dramatically increases the number of merge conflicts. And so on. Doing release planning at the end of the cycle ends up requiring more work (i.e. conflicts, merge headaches, a very slow release process) and can require pulling in dev resources to resolve merge issues (which interrupts their current work, and requires them to look at code that's no longer fresh in their mind, which is a very inefficient way to work.) In other words, prior planning prevents poor performance. Decide what's going into a particular release instead of using /trunk as a dumping ground for random changes, especially when those changes have dependencies (aka merge conflicts.) You'll probably want to triage your issues and assign them to a branch (e.g. fixVersion in JIRA.) Then use a pre-commit hook to reject check-ins unless the issue's fixVersion matches the branch. Meaning, don't allow 1.1 work to be checked into the 1.0 branch. 2)
RE: Merging change sets for a production release,
-Original Message- From: Gavin Baumanis [mailto:gbauma...@cogstate.com] Sent: Monday, June 03, 2013 2:27 PM To: Andrew Reedick; users@subversion.apache.org Subject: RE: Merging change sets for a production release, Hi Andrew, Thanks for your response. I do everything but for the chaining of the revisions to merge in the same command. I tried it once (granted a long time ago) and it caused such an issue for me that after about 6 hours of swearing, I finally gave up and reverted the changes and did the merges one by one. At the time one by one allowed for individual merge conflicts - which made life a little easier. As for the other ideas, we do already only merge changes from trunk that are complete and have been given the appropriate release milestone. Our release process is already issue-based. Perhaps simply chaining the merge revisions is the answer? Yes, I would try the 'svn merge -c ...' changed merge again. Assuming you're using SVN 1.7, chained merges should be much easier. It is still an iterative process, in that if a merge conflict is encountered, svn will prompt you for what to do, then you fix the code, resolve the conflict, and re-run the merge command to pick up where it left off. You will probably want to use 'svn merge --accept postpone ...' to avoid the prompting. It's normally a good idea to save off your merge command so you can add it to the commit comment (or in case anything happens to your command line's history buffer.)
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, May 21, 2013 10:24 AM To: Zé; users@subversion.apache.org Subject: RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? .. snip You keep saying svn doesn't support branches yet I use branches every day. While there is no way to list branches it would be possible. I think the current implementation records the parent path in the branch, but not vice versa... I assume svn doesn't do this because it would be a change to the parent path and the svn design avoids modifying the repository on its own. There are two definitions of branches; svn's definition of a branch (i.e. a dir) and the high-level definition of a branch (theory.) The reason why svn doesn't support branches is because a svn branch is just a dir, a dir that is only a branch because it is given special meaning by Humans. Internally, svn doesn't know or care if a dir is a branch or not. The distinction is important because one of the theoretical benefits of branching is isolation. An outside change shouldn't affect the branch's contents. Unfortunately, changing the parent path of a branch injects a spurious revision into 'svn log' and causes 'svn log --stop-on-copy' to stop early. This is detailed in my original email that started this thread. So when people say that svn doesn't have branches, they are saying that a) svn has directory objects, not branch objects, i.e. a svn branch is a branch by human convention only, b) svn dirs lack the special protections expected of branches (e.g. being isolated from outside change), c) svn dirs lack the special abilities expected of branches, such as computing ancestry reliably. Fortunately, in practice, dirs-as-branches works fine for the most part and any limitations tend to be minor. While there is no way to list branches it would be possible. No-ish. In the average case, list branches is easy. Just iteratively run 'log --stop-on-copy'. However, there are edge cases that prevent list branches from being deterministic or otherwise make determining ancestry complicated. For example, is this a rename (to fix a misspelling) or a case where someone combined two steps: 1) creating a new branch and 2) deleting an obsolete branch? svn copy branches/ofo-1.0 branches/foo-1.0 svn rm branches/ofo-1.0 svn ci ... creates revision 100 ... If I want to find the start of the branch, I run 'svn log --stop-on-copy ^/branches/foo-1.0' which will stop on revision 100. However, svn can't tell me if rev 100 is the start of the branch or whether it's just a spelling fix (in which case I need to run 'svn log --stop-on-copy' again.) Hopefully, the Human who created rev 100 provided a meaningful commit message.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Saturday, May 18, 2013 4:17 PM To: Zé Cc: users@subversion.apache.org; David Chapman Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? So what's the actual problem (or problems) with SVN's branching and tagging? Where does it hurt your workflow? What would make SVN not hurt you in that way? Please be concrete, and give examples of what really bothers you as a user or an admin in your daily work. Saying that branches are not first class, or I don't like it that Subversion implements branches/tags by copying directories are too abstract, and really not relevant. Why should I care how SVN implements its branches internally, as long as it works for the use cases I need? The only concrete problem I've read so far (I don't remember if it was in this thread or another one) is that copying the parent of all branches (or tags) shows up as a revision when you svn log the branch. So okay, that's one thing. Any others? Correct, changing the parent dir of a branch injects a spurious log entry in your branches (or tags) sub dirs, which is morally wrong because branches (and tags) should be isolated from outside changes. I documented this in the original post. (Or, given ^/porject1/branches and ^/porject1/tags, if you svn copy ^/porject1 ^/project to fix the naming problem then everything under branches and tags gets the spurious revision. The spurious revision also triggers on --stop-on-copy which needlessly complicates ancestry tracking. However, given how svn works, I'm not sure that it is technically a technical issue. =) Instead, is it a branches as first class objects requirement? However, this discussion lacks focus, it sounds more like a philosophical debate, with large ideas being thrown against each other. If you want to get anything useful out of this discussion (be it planting the seeds for improvements to Subversion, or be it a deeper understanding for yourself of how to work effectively with svn), you'll have to get much more concrete. IMO, it's not a philosophical debate per se, it's a requirements (or expectations) problem. We have two points of view. The first is the low-level technical point of view that is focused on being able to perform any operation at any point in the repository tree. The second is the high-level point of view that needs a VCS to manage baselines, track ancestry, track merges between baselines, etc. IMO, subversion right now is more of a VCS engine than a VCS system. Basically, it's the trees versus the forest view. The friction is that the high-level point of view folks are probably your primary customers. For example, when Subversion initially announced that merge tracking wasn't part of the initial architecture, I laughed and blew off svn as a complete waste of time due to intentionally lacking such a basic and essential VCS feature. Now that svn has implemented merge tracking, tree merging, and the long overdue death of --reintegrate in 1.8, I think it's getting close to the point that svn needs to step back and consider the forest view, e.g. true branches, proper ancestry tracking (instead of --stop-on-copy), etc., in order to maintain relevance. Meaning, svn's paradigm/workflow will need to focus on baselines (aka branches) instead of files and dirs because, in my experience, VCS users are most concerned about slinging baselines around and tracking changes to baselines (i.e. has all work for the release (baseline) been completed, merged, and tested?) Disclaimer: All IMHO.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, May 21, 2013 1:24 PM To: Andrew Reedick; Johan Corveleyn Cc: users@subversion.apache.org; David Chapman Subject: RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? What do you mean by spurious log entries? When I look at the log (at least in the tsvn log viewer) I only see revisions that have changes on that path. I don't see every revision number unless I go to the project root path or repository root path. 1. Create /tags/tag1, /tags/tag2, etc.. 2. Pretend that your tag1, tag2, etc. dirs are immutable, static, locked down, and haven't be touched in months. 3. svn log -v --stop-on-copy ^/tags/tag1 svn log -v --stop-on-copy ^/tags/tag2 etc. 4. # Move your tags dir under a project1 dir svn mv -m --parents ^/tags ^/project1/tags 5. svn log -v --stop-on-copy ^/project1/tags/tag1 svn log -v --stop-on-copy ^/project1/tags/tag2 etc. Ooops. All of your immutable, static, locked down, haven't been touched in months tags now have a new revision, and they all share that revision in common. The parent dir change from /tags to /project1/tags is visible under the tag1, tag2, etc. baselines because svn doesn't know that ^/project1/tags isn't/shouldn't be part of your tag1, tag2, etc. baselines. However, the Last Changed Revision of the tag1, tag2, etc. dirs doesn't change, so the effect is mostly visual.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Tuesday, May 21, 2013 11:41 AM To: Bob Archer Cc: Zé; users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? Of course you can 'list branches' as long as you follow and remember _your_ convention for where they are. You can also delete them to the extent that they don't show up in this list (even though they can still be accessed with peg revision syntax and the actions show in the log history of the parent directory). This is nicer in many ways than just having one special-case 'branch' namespace, especially when you have many projects in the same repository and/or you like to separate your release, QA, and experimental branches so different groups don't have to deal with the clutter from the others. Subversion doesn't force you to follow good conventions (and I think this thread started because someone didn't and the rename of a directory above where they put a branch was recorded as a change in both the branch and its parent), but you can if you want. Right, right, it's the user's fault for failing to predict future namespace needs. That the repository was created when the project was small and that the user in question inherited the repo aren't valid excuses either. Next time I'll implement top level directory changes via 'svnadmin dump/load' to avoid spurious log entries under branches/tags. Translation: Les, that wasn't a very realistic or helpful piece of advice.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Tuesday, May 21, 2013 2:33 PM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? I'd call realizing that most software isn't perfect being realistic, and learning to live with the imperfections to be more helpful than waiting for everything to work the way you expect. Maybe in this specific case some kind of event metadata could be added to note your intent to create a branch or tag and that could be used instead of -- stop-on-copy to avoid confusing what you think of as tags and other copies. Metadata could work. A svn mkbranch command that would run svn copy plus svn propset indicating that this is a branch root. svn copy would be restricted from operating in the branches or tags dir (as indicated by another property.) svn log --stop-on-branch would then check for the metadata. Although if I was going to modify the client that much, I might as well internally store branches as ^/UUID and map the UUIDs to a human label, e.g. project1/1.0 or project1/trunk. That would eliminate the troublesome admin level dirs from the repo and essentially implement true branches? And this would only be a presentation change thus negating the need to change how svn works internally.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: Tuesday, May 21, 2013 2:32 PM To: users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? On 21.05.2013 20:26, Branko Čibej wrote: You cannot identify a directory (or branch or tag) just by its basename, only the whole path is a unique identifier (within the repository). Yes, I understand why it happens and why it needs to happen. Just to be clear -- I agree that the the result of 'svn log --stop-on- copy' changes is confusing. And, as I said (much) earlier in this thread, that's an unfortunate side effect of how renames are currently implemented. Personally I've always viewed the --stop-on-copy as a hack, and we really should invent a better way of identifying branch points. I don't think true renames will necessarily fix the problem. Conceptually, the problem is that the parent dir components of a branch/tag are superfluous, e.g. given svn://server/repo/path/to/project1/branches/1.0, the svn://server/repo/path/to and branches path components are useless/meaningless to the average user. However, these superfluous dir components are visible to the client, which means they're accessible by, and thus modifiable by the client. Which makes them superfluous *and* dangerous. The client should only see and work with --project project1 --branch 1.0, e.g. svn co --project project1 --branch 1.0 to checkout a branch. It's about presentation. Keep the superfluous dir components internal and hidden from the average user. We've already seen a move towards information hiding with the'^' syntax that hides the server component. This would be the logical progression. Anyway, I'm nearly done with implementing my find common ancestor script that seems resistant to edge conditions, so I'll stop rambling.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: Tuesday, May 21, 2013 3:36 PM To: users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? On 21.05.2013 21:27, Andrew Reedick wrote: Anyway, I'm nearly done with implementing my find common ancestor script that seems resistant to edge conditions, so I'll stop rambling. Ah ... if that's what started the whole thread ... have you considered that the Subversion libraries already have that functionality, and that it's accessible through a number of script language wrappers? Will the libraries get tripped up by spurious revisions created by parent dir path changes?
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Tuesday, May 21, 2013 3:53 PM To: Andrew Reedick Cc: Branko Čibej; users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? The client should only see and work with --project project1 --branch 1.0, e.g. svn co --project project1 --branch 1.0 to checkout a branch. That's sort of like saying filesystems shouldn't have subdirectories so users don't get confused... Some people might even believe that. And there's a reason why 'pwd' returns '/home/userid' instead of '/dev/sda1/home/userid' or 'server-vol0.foo.net:/vol0/userid'. Or why 'cd ~' takes you to your home dir. It's about presentation. Keep the superfluous dir components internal and hidden from the average user. We've already seen a move towards information hiding with the'^' syntax that hides the server component. This would be the logical progression. It's about organization. And letting you arrange your own conventions to match your processes. We'll have to agree to disagree. We're back at the low level managing dirs versus high-level managing baselines arguments/thinking/paradigms.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: Thursday, May 09, 2013 4:35 PM To: users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? Well, given that you have not created any branches, this works as expected :) There are no branch points in your repository; only directories. A branch is created by copying a directory (with svn copy), not by creating it (with svn mkdir), and that is why your -- stop-on-copy works the way it does -- the only copy is a side effect of the rename (which is currently represented as copy+delete), hence -- stop-on-copy stops ... when it sees the copy. No, the effect is the same whether you use 'svn mkdir', 'svn copy', or 'svn mv', for single dirs or for trees full of files and subdirs. If you change the name or path of a parent dir, you implicitly create a common revision across each and every subdir and file. If you svn mv ^/tag ^/tags or svn mv ^/branches ^/project1/branches then everything under /tags or /project1/branches will now have a new, common, revision according to 'svn log'. It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.) I can understand why it happens; svn log needs to know about the parent dir rename in order to know (and print) the correct paths for subsequent revisions. It's a mostly harmless side effect of copy/mv, but it is odd looking and seems sloppy from a purist point of view because something outside of the branch is changing the branch's history and baseline albeit in a mostly limited fashion. Anyway, if you never restructure your high-level tags/branches/trunk dir structure and if you never rename a branch or tag, then you won't see this problem. The real problem here is that Subversion does not treat /renames/ as atomic operations. This is indeed being addressed, but a complete solution will take time. I'm not going to go into technical details here; if you're interested, you're welcome to join the dev@ list and listen in (or participate) in the discussions there. Yeah, I'm aware of the rename issue (I have a background in ClearCase,) but the 'lack of branches' is a whole issue in and of itself. A branch really should be a walled off garden until you explicitly merge.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Friday, May 10, 2013 9:57 AM To: Andrew Reedick Cc: Branko Čibej; users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? On Fri, May 10, 2013 at 09:40:48AM -0400, Andrew Reedick wrote: It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.) It is strange behaviour on a conceptual level if you are used to thinking in terms of other version control systems (such as ClearCase in your case). However, it is a natural consequence of the way Subversion is currently supposed to represent the concepts of versioning files and directories, and labels and branches. And it has done so for over a decade. Changing this behaviour is far from trivial. I'm not entirely sure what kind of answer you are hoping to get. Are you happy with the answer that Subversion is simply not ClearCase? I've been using svn since 1.3, so I'm aware of the design limitations. And yes, I would recommend svn over clearcase in most situations. Anyway, the whole exercise started when I needed a report script to find the common ancestor between two branches and ran into the 'parent dir change false revision' issue. Then I started going through potential edge cases and realized just how fragile svn branches were (where fragile == dependent on human processes and conventions.) Which in turn made me realize just how basic (i.e. bare metal) svn is in regards to meta-features such as branching, tagging, baselines, workflows, etc.. It makes me wonder if it would make sense to slap a higher-level interface on top of svn in order to implement the process aspects of version control (and otherwise hide/keep the lower level details/quirks away from users.)
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Friday, May 10, 2013 11:00 AM To: Andrew Reedick Cc: Branko Čibej; users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? On Fri, May 10, 2013 at 8:40 AM, Andrew Reedick andrew.reed...@cbeyond.net wrote: It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.) I can understand why it happens; svn log needs to know about the parent dir rename in order to know (and print) the correct paths for subsequent revisions. It's a mostly harmless side effect of copy/mv, but it is odd looking and seems sloppy from a purist point of view because something outside of the branch is changing the branch's history and baseline albeit in a mostly limited fashion. Isn't this just a difference in subversion's and your thinking about the significance of the path change? Subversion is going to see the path change affecting everything below it because of the way it holds projects together. Is there some reason you are changing a common parent path and thinking that it should not affect everything below? Is it 'above' what you think of as the actual project? Two words: meta data. A change in meta-data shouldn't change a branch's baseline. Moving /trunk to /project1/trunk shouldn't change the contents of the trunk baseline. Renaming a misspelled branch (/branches/rle1.0 to /branches/rel1.0) shouldn't change the contents of a branch/baseline. So, from a technical point of view, where svn has dirs, not branches, then yes, I would expect a parent dir change to do what it did. From a process/philosophical point of view where branches represent baselines, then I would not expect a parent dir change to do what it did. Anyway, it represents just one more potential quirk that you have to be aware of when using svn. Fortunately, it's mostly harmless. Long term, once svn's lower level features are mature (true renames, getting rid of --reintegrate, etc..) I would expect a push towards high-level process features such as branches as first class objects.
RE: How to remove revision number in mergeinfo eligible list
From: Z W [mailto:mpc8...@gmail.com] Sent: Wednesday, May 08, 2013 8:25 PM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: How to remove revision number in mergeinfo eligible list Hi Andrew Thanks for taking the time to respond. We did as told step by step and the result is the same - revision number is still in eligible list at the final step [root@host newbranchWC]# svn mergeinfo --show-revs eligible https://some.url.com/svn/root/trunk r6554 r9946 [root@host newbranchWC]# svn propget svn:mergeinfo . /root/trunk:6560,9804,9806,9836,9874-9876,9880-9881,9899-9900,9951-9952 [root@host newbranchWC]# svn merge -c 6554 --record-only https://some.url.com/svn/root/trunk [root@host newbranchWC]# svn propget svn:mergeinfo . /root/trunk:6560,9804,9806,9836,9874-9876,9880-9881,9899-9900,9951-9952 [root@host newbranchWC]# svn mergeinfo --show-revs eligible https://some.url.com/svn/root/trunk r6554 r9946 We wonder if it has to do with the rev number change itself. That 6554 rev number is about /root/Trunk creation from svn mkdir The following rev number 6560 is about renaming /root/Trunk to /root/trunk Then the following rev number 9804 is about svn copy of dir A to https://some.url.com/svn/root/trunk/A Then the following rev number 9806 is about svn copy of dir B to https://some.url.com/svn/root/trunk/B Would such actions impact the very first rev number for folder https://some.url.com/svn/root/Trunk ? We use SVN 1.6 The good news is that I was able to do a merge that produced output similar to yours. The bad news is that you are probably merging unrelated branches... What branch is your workspace set to? (svn info) And what is the common ancestor between /root/Trunk and the workspace branch? You can try 'svn merge --ignore-ancestry', but I don't think it will make a difference since your branches are probably very unrelated. In other words, 'svn merge' should have produced some output. The fact that it didn't implies that there was no merging to be done. I have no idea why 'svn mergeinfo --show-rev eligible' would still list revs.
Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Problem: Subversion doesn't have branches. Subversion has directory objects, and we Humans(tm) arbitrarily decide that some directories are branches, thereby giving these directories (branches) magical powers and mystical significance. Meanwhile, Subversion grinds on, treating those magic branches as mundane directories. You can see the effects of this problem when you change a parent directory common to multiple branches, e.g. changing /projectFoo/branches to /projectBar/branches will cause every branch in /projectBar/branches/* to have a shared revision. This complicates finding branch points (--stop-on-copy), finding the common ancestor, etc.. Are there any plans to address this issue or otherwise make branches a first class object? Or at least add a switch to 'svn log' to skip over extraneous only the parent dir path changed revisions? Demonstration: $ svn mkdir -m ^/project1/branches Committed revision 73. $ svn mkdir -m ^/project1/branches/alpha Committed revision 74. $ svn mkdir -m ^/project1/branches/beta Committed revision 75. $ svn log -q -v ^/project1/branches/alpha r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013) | 1 line Changed paths: A /project1/branches/alpha $ svn log -q -v ^/project1/branches/beta r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013) Changed paths: A /project1/branches/beta As you can see from the svn logs, the alpha and beta branches are completely independent. They have no revisions in common. But by renaming the parent project1 dir to project100, we create a linkage between the two: $ svn mv -m ^/project1 ^/project100 Committed revision 76. $ svn log ^/project100/branches/alpha r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013) Changed paths: A /project1/branches/alpha $ svn log ^/project100/branches/beta r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013) Changed paths: A /project1/branches/beta Note that the independent branches alpha and beta now have revision 76 in common... even though neither branch was changed. Adding insult to injury, svn log --stop-on-copy will stop on revision 76, i.e. it treats r76 as a branch point: $ svn log --stop-on-copy -v ^/project100/branches/alpha r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) $ svn log --stop-on-copy -v ^/project100/branches/beta r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013) Changed paths: D /project1 A /project100 (from /project1:75) As you can see, the independent alpha and beta branches now have revision 76 in common. All because Subversion doesn't have branches. /grumble
RE: mergeinfo between svn copied branches and merges
From: Z W [mailto:mpc8...@gmail.com] Sent: Wednesday, May 08, 2013 6:49 AM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: mergeinfo between svn copied branches and merges In this case, all you should have to do is: a) merge branchC UP to branchB b) merge --reintegrate branchB DOWN to branchC. Step a) will pick up any branchA changes (because all of branchA is a subset of branchC.) This strategy is still new to us. We're not sure what the intermediate steps are trying to accomplish, esp the merge up and down parts. What is the exact syntax (as an example) for (a) and (b) ? a) merge branchC UP to branchB cd branchB_workspace (or create a brand new, clean workspace) svn status (check for existing changes) svn update (If your workspace is not up to date, svn merge will complain.) svn merge svn://.../branchC resolve any conflicts svn ci b) merge --reintegrate branchB DOWN to branchC. cd branchC_workspace (or checkout a clean workspace) svn status svn update Notify folks to not check into branchB, or simply lock branchB (since we will need to delete branchB) svn merge --reintegrate svn://.../branchB resolve any conflicts svn ci svn log -l 3 svn://.../branchB (Since we're going to delete branchB, make sure that no one checked into branchB after your merge) svn rm svn://.../branchB svn copy svn://.../branchC@1234 svn://.../branchB (recreate the branchB if it is still needed.) where 1234 is either the HEAD of branchC or the merge point on branchC. It's up to you. This is covered in the svn book: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate UP/DOWN: You merge UP to a child branch that was created from a parent branch. You merge back DOWN to a parent branch from a child branch. UP and DOWN are just semantics to help you keep things straight due to the need to run --reintegrate. Once svn 1.8 comes out, you shouldn't have to worry about up, down, and --reintegrate anymore. we svn copy branchA to produce branchB In this case, branchA is the parent, and branchB is the child, so you merge UP from A to B, and DOWN (via --reintegrate) from B back to A. In the example given in the svn book, branchA would be the calc-trunk and branchB would be my-calc-branch. we then svn copy branchA to produce branchC Since branchC was created from branchA, branchC would still be the parent of branchB. Merge UP to branchB, merge DOWN to branchC. Of course, this is Subversion, and merge tracking wasn't part of the original design specs, so there's always the chance of something odd happening... Branching and merging: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html
RE: svn issue
You can do a fresh checkout and not include project10 in the initial update:
svn co -N svn://.../top_dir
cd top_dir
cd svn update project1 project2 ... project 9
Future 'svn update' commands in the top_dir directory will only update projects
1 through 9.
Or you can explicitly not update project 10:
Windows CMD shell:
for /f %i in (' svn ls ^| findstr /v project10') do @svn update %i
ksh/bash:
svn ls | grep -v project 10 | xargs svn update
Disclaimer: Top posting because Outlook has crushed my spirit.
From: Amit Kumar [IN7537] [mailto:amit_ku...@mindtree.com]
Sent: Wednesday, May 08, 2013 3:26 AM
To: users@subversion.apache.org
Cc: amitsinghra...@gmail.com
Subject: svn issue
Hi,
I found an issue in SVN. Suppose there are 10 project is in directory. And I
want to update only 9 project. There is no option to lock one project not to
update.
By this issue I get problem. I will request you to solve this issue.
Thanks Regards,
Amit kumar | Senior Software Engineer | P +91 80 670 60718 | M +91 9740012743 |
www.mindtree.comhttps://indiamail.mindtree.com/exchweb/bin/redir.asp?URL=http://www.mindtree.com/
MindTree Limited | West Campus, Global Village, RVCE Post, Mysore Road,
Bangalore, India - 560 059 | Welcome to possible
http://www.mindtree.com/email/disclaimer.html
RE: How to remove revision number in mergeinfo eligible list
From: Z W [mailto:mpc8...@gmail.com] Sent: Wednesday, May 08, 2013 3:05 PM To: users@subversion.apache.org Subject: How to remove revision number in mergeinfo eligible list Hi All We use SVN 1.6 We have a revision number which refuses to move to the merged list after applying a merge. [root@host branchWC]# svn mergeinfo --show-revs eligible https://some.url.com/svn/root/trunk r6554 [root@host branchWC]# svn merge -c 6554 --record-only https://some.url.com/svn/root/trunk [root@host branchWC]# svn propget svn:mergeinfo . It returns empty. How do we remove revision number in mergeinfo eligible list or force it to move to the merged list ? We cannot use regular merge for this rev number, unfortunately. Any help is appreciated. Sincerely That's odd. Compare the pre-merge svn:mergeinfo with the post-merge copy to see if anything was changed: svn propget svn:mergeinfo https://.../root/trunk a.txt svn propget svn:mergeinfo . b.txt diff a.txt b.txt If you run mergeinfo again (after the merge), does 6554 still show up in the list? svn mergeinfo ... | grep 6554 Do you see a trailing asterisk (*) for the branch in svn:mergeinfo? Ex: /branches/1.0:3166-3179* If so, then there might be some quirk in how svn is recording a partially merged range. Is it missing from all the svn:mergeinfo properties? (Run 'svn status' and run 'svn propget...' on the dirs with a 'M' in the second column.)
RE: How to remove revision number in mergeinfo eligible list
From: Z W [mailto:mpc8...@gmail.com] Sent: Wednesday, May 08, 2013 4:09 PM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: How to remove revision number in mergeinfo eligible list Hi Andrew Thanks for responding; appreciate it. We followed your instruction - svn propget svn:mergeinfo https://.../root/trunk a.txt svn propget svn:mergeinfo . b.txt diff a.txt b.txt a.txt returns an empty file b.txt returns empty too. The revision number 6554 change is about the creation of the trunk (https://.../root/trunk). In this trunk it has 2 directories A and B. In our working copy directory, it has directories A and B, too. We're trying to merge from the trunk to working copy branch svn mergeinfo ... | grep 6554 returns empty. Okay... let's try this again. 1. checkout a clean workspace. 2. cd workspace 3. svn mergeinfo --show-revs eligible https://some.url.com/svn/root/trunk pre-mergeinfo.txt 4. svn propget svn:mergeinfo . pre-prop.txt 5. svn merge -c 6554 --record-only https://some.url.com/svn/root/trunk 6. svn propget svn:mergeinfo . post-prop.txt 7. svn mergeinfo --show-revs eligible https://some.url.com/svn/root/trunk post-mergeinfo.txt 8. diff pre-mergeinfo.txt post-mergeinfo.txt I expect r6554 to be in pre-mergeinfo.txt and not in post-mergeinfo.txt. 9. diff pre-prop.txt post-prop.txt If these files are different, then svn:mergeinfo was updated.
RE: mergeinfo between svn copied branches and merges
From: Z W [mailto:mpc8...@gmail.com] Sent: Tuesday, May 07, 2013 11:53 AM To: users@subversion.apache.org Subject: mergeinfo between svn copied branches and merges we have branchA we svn copy branchA to produce branchB branches A and B continues development and checkins branchA is merged to branch B continuously branchA finishes, tagged we then svn copy branchA to produce branchC we like to continue branchC merging to branchB we hear u clearly that the merge info are copied between branches we performed svn mergeinfo merged on branchB working copy with branchA we could see the correct list of merged rev numbers we performed svn mergeinfo eligible on branchB working copy with branch A; we see correct list of eligigle rev numbers we learn that these numbers are used by SVN to calculate what needs to be merged from branchB to branchA (-reintegrate) we performed svn mergeinfo merged on branchB working copy with branchC we see a new list (not including list of merged rev numbers from branchA) we learn that if we reintegrate from branchB to branchC, because those list of merged rev numbers from branchA are not there, SVN would not know those rev numbers changes already exist in branchC so SVN would try to reintegrate those list of merged rev numbers from branchA on branchC thus causing tree conflict. Svn will implicitly know about the rev numbers from branchA because branchA is a subset of branchC. Go here http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata and read Natural History and Implicit Mergeinfo. In this case, all you should have to do is: a) merge branchC UP to branchB b) merge --reintegrate branchB DOWN to branchC. Step a) will pick up any branchA changes (because all of branchA is a subset of branchC.) If you did additional work on branchA *after* creating branchC, then you would need to: a) merge branchA UP to branchB, b) merge branchC UP to branchB, c) merge --reintegrate branchB down to branchC.
svn log --xml --use-merge-history ... doesn't include --use-merge-history in the xml output?
Is it just me or is svn log's --xml switch not including --use-merge-history information? The text output of svn log --use-merge-history includes the Merged via: r3673 information: r3584 | bob | 2013-04-16 15:50:48 -0400 (Tue, 16 Apr 2013) | 1 line Merged via: r3673 Fixed flux capacitor whereas svn log --xml --use-merge-history provides no Merged via: ... information: logentry revision=3584 authorbob /author date2013-04-16T19:50:48.762112Z/date paths path kind=file action=M/project/branches/1.1/source/foo.jcl/path /paths msgFixed flux capacitor/msg /logentry This is with the svn CLI client, version 1.7.9 (r1462340)
RE: svn log --xml --use-merge-history ... doesn't include --use-merge-history in the xml output?
-Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Wednesday, May 01, 2013 4:24 PM To: users@subversion.apache.org Subject: svn log --xml --use-merge-history ... doesn't include --use-merge-history in the xml output? Is it just me or is svn log's --xml switch not including --use-merge-history information? The text output of svn log --use-merge-history includes the Merged via: r3673 information: r3584 | bob | 2013-04-16 15:50:48 -0400 (Tue, 16 Apr 2013) | 1 line Merged via: r3673 Fixed flux capacitor whereas svn log --xml --use-merge-history provides no Merged via: ... information: logentry revision=3584 authorbob /author date2013-04-16T19:50:48.762112Z/date paths path kind=file action=M/project/branches/1.1/source/foo.jcl/path /paths msgFixed flux capacitor/msg /logentry Bah, never mind. In the xml, the entries for the merged revisions are sub-nodes of the logentry, e.g. logentry revision=3755 authorbob_porter/author date2013-05-01T18:43:40.613101Z/date msgcomment/msg logentry revision=3754 authorbob_slydell/author date2013-05-01T17:53:15.616621Z/date msgstock option equity sharing program/msg /logentry logentry revision=12345 ... /logentry /logentry
RE: Keyword substitutions not being merged correctly
From: David Sandberg [mailto:david.sandb...@hickorytech.com] Sent: Wednesday, March 20, 2013 1:18 PM 1) User Jim commits a new file A with the Revision keyword to the trunk in revision 101. 2) User Sam merges trunk revision 101 into his feature branch, and the new file A comes across fine and shows revision 101 in the keyword substitution part of the file. 3) Jim commits an update to file A to the trunk, in revision 200. (If other users who are working in the trunk pull this file at this time, it updates and the keyword in their updated file correctly reads 200.) 4) Now, Sam merges trunk revision 200 into his feature branch. The merge happens automatically without prompts for conflicts or anything, and the resulting file A contains MOST of the changes from the trunk revision ... EXCEPT for the Revision keyword, which stays at 101! As Thorsten pointed out, the keywords do not store the actual revision number. Only the unexpanded $Rev$ is stored on the server. Its sounds like svn:keywords isn't set correctly on Sam's feature branch. Whenever a new revision of a file is created (such as after a merge) the revision keyword should match the Last Changed Rev: (which you can see when you run svn info on the file.) What does Sam see when he runs svn info in step 4? After Sam's merge in step 4 (and before Sam's commit,) does a svn diff show any differences in the file? If the merge didn't actually change anything, then the file won't change, so the Last Changed Rev: doesn't change, so the revision keyword doesn't change. Also, you won't see the revision keyword change in the file until after you do a commit.
RE: Keyword substitutions not being merged correctly
-Original Message- From: David Sandberg [mailto:david.sandb...@hickorytech.com] Sent: Wednesday, March 20, 2013 2:52 PM Thank you for that crystal clear explanation, which accounts perfectly for the observed behavior. I will add that I am not sure I agree with the correctness of that behavior, but that's only because it doesn't happen to fit our operational model, in which we cherry-pick revisions from the trunk into our release branch and then build archives for deployment to customers. The problem is that the resulting deployed files need to reflect the revision numbers that were committed into the trunk ... or at least some newer revision number than in previous builds. From what you've described, we could perhaps achieve that by committing the merged set of files to our release branch before we begin a build, but that seems like a backwards way to go about things when we may find ourselves still needing to make updates as part of completing the build, so we would be committing potentially broken revisions in order to get these keyword substitutions to update before the build process runs. That's why we grab the 'Last Changed Rev: of the root directory of the release tree and use that as the release number. The root revision is guaranteed to change if there's a change anywhere in its subtree. In my experience, trying to manipulate meta-data inside of the files is just not worth the effort except in one-off script files. Meaning, why are you storing information *about* the file *inside* of the file? (And even in the case of one-off files, I'm more interested in the svn URL than the actual revision number.) IMO, you would skip a lot of angst if you just update the keywords during your release packaging process, i.e. have your build/packaging script walk the files and update the keywords manually. Even so, keywords don't really provide much value, in that they don't tell you what the correct revision should be (i.e. is the correct release installed?) nor do they reveal file tampering (i.e. production changes.) IMO, you need to adopt a proper installer script and create an audit script. (Gnu tar has a --diff option, which gives you quick and dirty packaging, deployment, and auditing functionality.) Once you have those in place, the need for revision keywords goes away.
RE: svn:externals - process question
As you've discovered, externals *always* pull in the HEAD revision unless you specifically add a revision number to the svn:externals property. Needless to say, rogue svn:externals are bad for build reproducibility and tagging. Options are: Audit the svn:externals (either manually, via a check-in hook, in the build/tagging script, etc.) in your checkedout/exported code to check for rogue svn:externals that are not locked down to a specific revision number. If there are rogue svn:externals, then you'll need to branch/tag and update the svn:externals before doing your build, or reject the code drop until the svn:externals are fixed. Another similar alternative as you've stated, is to only allow svn:externals that point to tagged code. If you want don't want to validate externals on the front end, you can try recording the externals after the fact. If you do a checkout of the code, you can cd into each external and get the revision number (via svn info.) Or you could parse the output of svn co or svn export to get the revision numbers of the externals items and record them somewhere. (svn update will also return the revision numbers of externals.) Ex: Create the tag, run svn co tag, record the revision numbers pulled in, go back and add -r 123 to the svn:externals in the tag branch. However, I haven't checked how nested externals are handled, e.g. your external reference could contain svn:externals which could have svn:externals of their own, ad infinitum. A really simple option is to export the code (including externals) and then import the code again as its own tag. Needless to say this breaks history, but it does guarantee that you can reproduce the build. Using --ignore-externals isn't normally practical.
