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&data=02%7C01%7Cjre > >|edick%40incomm.com%7Cbf08bacf2e7f48e9062108d4d9683be1%7Cd08e5403b1c94d > >|bfaf91bab966a84dea%7C1%7C0%7C636372489093013309&sdata=%2BS0P8L4moTaajr > >|L5XQS%2BIc4ln8hyEci1GdDKhYkh1eE%3D&reserved=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&data=02%7C01%7Cjreedick%40incomm.com%7Cbf08bacf2e7f48e9062108d4d9683be1%7Cd08e5403b1c94dbfaf91bab966a84dea%7C1%7C0%7C636372489093013309&sdata=%2BS0P8L4moTaajrL5XQS%2BIc4ln8hyEci1GdDKhYkh1eE%3D&reserved=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 vs. git
It’s been awhile, but isn’t changing the commit message (after a push) potentially problematic in git?
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
> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: Friday, October 14, 2016 9:38 AM > To: users@subversion.apache.org > Subject: Re: [Linux] Hook hashbang hardships > > On 14.10.2016 14:58, Andrew Reedick wrote: > >> 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 > > > You really need to read the manpage, which says: > > All of the single-character shell options documented in the > description of the *set* builtin command can be used as options when > the shell is invoked. Let's go all the way down the rabbit hole: http://ss64.com/bash/set.html -e Exit immediately if a simple command exits with a non-zero status, unless the command that fails is part of an until or while loop, part of an if statement, part of a && or || list, or if the command's return status is being inverted using !. -o errexit Plan B; add -x to see what's going on: #!/bin/bash -ex
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
> 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: Svn rename doesn't copy custom properties
Works for me. svn, version 1.8.10 (r1615264) Windows 7 C:\Users\jdoe\workspace\foobar>svn pl -v A.txt Properties on 'A.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c C:\Users\jdoe\workspace\foobar>svn rename A.txt AA.txt A AA.txt D A.txt C:\Users\jdoe\workspace\foobar>svn pl -v AA.txt Properties on 'AA.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c C:\Users\jdoe\workspace\foobar>svn 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_v2>svn pl -v A.txt Properties on 'A.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c c:\Project_files\sandbox_v2>svn rename A.txt AA.txt A AA.txt D A.txt c:\Project_files\sandbox_v2>svn pl -v AA.txt c:\Project_files\sandbox_v2>svn pl -v REN.txt
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 > /db/fs-type says "fsfs" then the repository format > (/format) is probably 3 and you're talking about /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 > /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 > /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: Andrew Reedick [mailto:jreed...@incomm.com] > > > > On Apr 28, 2015, at 2:03 PM, Andrew Reedick 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=469&expandFolder=469&folderID=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.
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 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=469&expandFolder=469&folderID=11149
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."
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.
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?
"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:
andrew
2014-01-16T19:41:15.571931Z
/trunk
/trunk/a.txt
svn merge -c -15 .
==>
andrew
2014-01-16T19:37:17.531316Z
/branches/test/a.txt
branch 3
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. 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.
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: 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: 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 > 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 cp-pfoobar 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 2>&1 to: find . -type f while read i do sed 's/e/E/g' $i done foo.txt Simple and inherently accurate, natch?
RE: svn diff on root folder (like d:\) crash on Windows
> From: Michel Archambault [mailto:micj...@gmail.com] > Sent: Wednesday, November 13, 2013 12:25 PM > To: users@subversion.apache.org > Subject: svn diff on root folder (like d:\) crash on Windows > > > > Bug found on: > - Windows 7 64-bit > - svn 1.8.4 > - Working copy in d:\ directly (not in a sub-folder like d:\MyTrunk\) > > Step: > In a command prompt do > cd /d d:\ & svn diff > C:\Validpath.patch > where d:\ is a working copy. > > What happen: > - a GPF (crash) of svn > - The file C:\Validpath.patch is created but empty (0 KB). > > > Previously work well in svn 1.7.x > > Confirmed in 1.8.3 with Windows 7 32 bit. svn, version 1.8.3 (r1516576) compiled Aug 28 2013, 10:07:20 on x86-microsoft-windows 0. Start CMD. 1. cd c:\ 2. svn co -N svn_url . Don't forget the trailing dot. Checkout a directory without any files in it if you don't want to mess up your root dir. 3. mkdir foo 4. date > foo\a.txt Hit return a few times to create the file. 5. svn add foo 6. svn diff 7. Boom. Specifically, from the event viewer: Faulting application name: svn.exe, version: 1.8.3.9248, time stamp: 0x521db045 Faulting module name: libsvn_subr-1.dll, version: 1.8.3.9248, time stamp: 0x521dafbf Exception code: 0xc005 Fault offset: 0x00089f57 Faulting process id: 0xe468 Faulting application start time: 0x01cee09787232137 Faulting application path: C:\Program Files\Subversion\bin\svn.exe Faulting module path: C:\Program Files\Subversion\bin\libsvn_subr-1.dll Report Id: c4f9d99e-4c8a-11e3-a0b5-0021ccc90765 Notes: If there are no changes to the workspace, "svn diff" doesn't fail: a) svn revert -R . b) svn diff
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?
> -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: 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: Branch changes
> -Original Message- > From: John Maher [mailto:jo...@rotair.com] > Sent: Tuesday, October 08, 2013 10:14 AM > To: Andy Levy > Cc: Subversion help > Subject: RE: Branch changes > > Thanks for your reply Andy, that was helpful. For anyone else interested, to > get the revision where the branch was created you can do this: > "svn log --verbose --stop-on-copy URL_TO_BRANCH" > The last line indicates what revision the branch was created. Unless, of course, you renamed your branch, e.g. 'svn mv rel-1.2 rel-2.0', or if you renamed/moved the parent directory components, e.g. 'svn mv /branches /project1/branches' in which case you will need to run the 'svn log --stop-on-copy -r REV-1' iteratively (where 'REV-1' is the revision returned by --stop-on-copy minus 1,) until you get to the "real" branch point. /pedantic Also, if you want 'svn log --stop-on-copy' to return just a single revision, you can use --limit thusly: svn log -v -r1:HEAD --stop-on-copy --limit 1 ^/branches/my_branch
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 > 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.
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.
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. =) /
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
> -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?
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".
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: 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:/dir>svn 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:/dir>svn 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: 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: 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: 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
> -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: 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. The
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: 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 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;
}
}
}
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: "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*
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: 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
To add insult to injury, TortoiseSVN's add just died on a .css file: C:\temp\test18\foo\src\main\webapp\css C:\temp\test18\foo\src\main\webapp\css\jquery.fancybox-1.3.4.css File 'C:\temp\test18\foo\src\main\webapp\css\jquery.tooltip.css' has inconsistent newlines Inconsistent line ending style Additional errors: Inconsistent line ending style TortoiseSVN 1.8.0, Build 24401 - 32 Bit , 2013/06/17 18:15:59
"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
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: Ancestrally Related Error Message
> From: C M [mailto:cmanalys...@gmail.com] > Sent: Monday, June 17, 2013 12:39 PM > To: C. Michael Pilato > Cc: Subversion > Subject: Re: Ancestrally Related Error Message > > I think my earlier mistake might have been that I was using the --reintegrate > option. > Without it, I make some progress, but still not quite what I am expecting. > Again, given that trunk is empty, why the "C" (tree conflicts)? I would > expect all of then to be "A" (additions), no? > The DEV_WC currently only shows the two dirs which SVN correctly recognized > as additions. > > c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry > https://path_to_branch/SCR_BR/ > > --- Merging r1191 through r1245 into '.': > C ini > C txt > C graphics > C MMI > C backups > C sysctrl > C cpu > A mtl > Summary of conflicts: > Tree conflicts: 8 What kind of tree conflicts are they? 'svn status' should provide more detail. Also, what version of svn are you using? 1.6? 1.7? Why is trunk empty? Because you deleted trunk after the branch was created? (i.e. create branch, delete trunk/*, merge from branch.) I get the vague feeling that you have 'incoming add after delete'(?) type messages on the directory conflicts.
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 t
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 : > @revnumber > But it is not possible to use a syntax like this : > @revnumber/ 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 > > A my_project_03b_pristine/Project/settings/MkSharedData.exe > C my_project_03b_pristine/Project/settings/MkImage > A my_project_03b_pristine/Project/settings/MkImage/main.c > A my_project_03b_pristine/Project/settings/MkImage/defs.h > A my_project_03b_pristine/Project/settings/MkImage/Makefile > A my_project_03b_pristine/Project/settings/hex_to_hex.exe > > user_dude@computer_node~/projects/my_project/my_project_03b_pristine > $ 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 Duh. The 'C' is in the 2nd column, which means there's a conflict with the properties. However, I'm not sure why you would have a properties conflict on a checkout in svn 1.7.
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: 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: 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: 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 bra
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: 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: 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: 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: 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: 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: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: Tuesday, May 21, 2013 12:30 PM > To: users@subversion.apache.org > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > Guten Tag Bob Archer, > am Dienstag, 21. Mai 2013 um 17:54 schrieben Sie: > > > Frankly, if you are > > writing to tags it is more like a branch. ;) > > Of course, that's why it's all about definitions or conventions and my > writable tags are customer installations of our software which get > updated to new versions and are used to track configuration changes. > Nothing I would like to implement using only top level branches and as > no active development takes place on those directories, I see them > rather as tags, than branches. > I think of tag-branches as effort saving devices that spare me from having to svn copy tags/PRODUCTION branches/production vi branches/production/config.conf ... svn rm tags/PRODUCTION svn copy branches/production tags/PRODUCTION when a hostname changes in prod and I need to backfill a config file. Should we call them tag-branches or branch-tags? And should they be first class objects? ;-)
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 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: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Wednesday, May 15, 2013 11:05 AM > To: Zé > Cc: Subversion > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > On Tue, May 14, 2013 at 3:33 PM, Zé wrote: > >> > > What has been said regarding > > subversions lack of support for branching was, I think, quite clear. > > Well, no. The only thing you've made clear is that you don't like it > or you don't understand how it is supposed to be used. You have not > explained why you lay your projects out so that you need to move the > parent directories of your project around after creating branches. > Nor have you made any real suggestions about how it might be improved > in a way that doesn't break the ability to copy and subsequently merge > any arbitrary subdirectory which is clearly a feature even though it > doesn't mesh well with your concept of only having one way to branch. > Isolating change is a fundamental tenet behind branching. The fact that an "outside" change can affect a branch (and a tagged baseline) is wrong by definition. Telling folks to never change their branching structure is a bit short-sighted given the lack of reliable precognitive ability in general and that occasionally folks like to clean up the branches and tags dir when they're cluttered with dozens of old branches and tags. Telling folks not to run 'svn mv tags/1.0* archive/' simply isn't helpful. Plus, telling people not use to svn's touted directory manipulation features because of side-effects is a bit self-defeating. As for the various CVS comments in the thread, no one cares if Subversion was originally meant to be a better CVS. Building a better CVS is akin to saying "let's build a better Model-T". Personally, when it was announced that svn wouldn't include merge tracking, I wrote off SVN as useless for not including the basics. Fortunately, merge-tracking and merging have come a long way since then and I, for one, am looking forward to 1.8 driving a stake in --reintegrate. Furthermore, Subversion's vision statement is: "Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations." In the Future(tm), Subversion, IMHO, will need to treat branches (and tags) as first class objects because branches and tags are core concepts of modern version control systems. To re-emphasize my point, isolated branches are an expected, fundamental, expected, and/or part of a minimal set of features that any VCS must support. So please, no more references to "svn being a better CVS". It's a very limiting and short-sighted thing to say. Fortunately, the "parent dir changes affect branch history" problem is a minor hiccup. There's no need to grab torches and pitchforks and rush to implement formal branches right now. It's just something that needs to be kept in the back of people's minds once the merging, tree merging, and true renames are implemented and are mature. I think that most folks can live with a spurious revision appearing in 'svn log' entry after a parent dir change.
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 > 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: 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: 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.
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: 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.
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: 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: 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.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: 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: 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.
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: > revision="3584"> > bob > 2013-04-16T19:50:48.762112Z > > kind="file" >action="M">/project/branches/1.1/source/foo.jcl > > Fixed flux capacitor > Bah, never mind. In the xml, the entries for the merged revisions are sub-nodes of the logentry, e.g. bob_porter 2013-05-01T18:43:40.613101Z comment bob_slydell 2013-05-01T17:53:15.616621Z stock option equity sharing program ...
"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: bob 2013-04-16T19:50:48.762112Z /project/branches/1.1/source/foo.jcl Fixed flux capacitor This is with the svn CLI client, version 1.7.9 (r1462340)
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: 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: 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.
