On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote: > Hi, > > On 05.04.10 17:06, Stefan Sperling wrote: > >On Mon, Apr 05, 2010 at 04:14:21PM +0200, Martin Hauner wrote: > >[..] > >>In case of merging (mostly cherry picking from trunk to live and > >>next release branches, merge tracking is nice BUT svn:merginfo on > >>the root folder kills it again. After each merge I have to update > >>again (ie. wait another few minutes) before I'm able to commit > >>again. > > > >So mergeinfo kills it because it takes a long time to update? > >How is this any different from the performance problem you mentioned, > >and what has it got to do with mergeinfo? > >Or do you generally oppose the idea of storing merge information > >in svn: properties? If so, were else would you store it? > > Äh, performance yes. ;-) > > The performance problem makes merge tracking more a pain than a gain. > > Before merge tracking I could do this: > > merge (cherry pick) from trunk to branch > commit, add merged revision to log message > merge (cherry pick) from trunk to branch > commit, add merged revision to log message > > and so on... > > In most cases this didn't touch common folders so while updating my > branch I could mostly skip the update step. > > With svn:mergeinfo I have to update after each commit because its on > my root folder and always is out of date on the next commit.
The out-of-dateness really comes from the mixed-revision working copy concept, not from mergeinfo. The root of your working copy is not out of date right after the commit. It is at the HEAD revision after commit: $ ls alpha beta epsilon/ gamma/ $ svn merge ^/trunk --- Merging r2 through r4 into '.': U alpha --- Recording mergeinfo for merge of r2 through r4 into '.': U . $ svn ci -m merge Sending . Sending alpha Transmitting file data . Committed revision 5. $ svn info . | grep ^Rev Revision: 5 Maybe you do not commit the mergeinfo which is set on the root of your working copy? If so, why not? Or maybe you don't realise that you always have a mixed-revision working copy after a commit? Even if the root folder is at HEAD, it may be "incomplete" because some of its children aren't at HEAD yet. So Subversion may not allow you to commit some of the children (because they really are out of date and it has to check the repository for new changes and maybe get them, which is what update is for). So, in general, you need to run svn update to bring mixed-revision working copies to a single revision. Of course, if update is so slow that you avoid using it, you will end up with many of the files and folders in your working copy at different revisions, and you'll often run into "out of date" errors. But that still seems to point to the performance problem with update. So I see several factors which cause the problems for the work flow you would like to use: - subversion supports mixed revision working copies, which has implications on the working copy state after commit, and which means you should update your entire working copy after every commit if you want single-revision working copy behavior - mergeinfo is stored as a property, so it is handled like any other versioned data, and you need to commit it, causing mixed-revision working copies - update is too slow We can't really toss the mixed-revision working copy concept. Doing that would force users of busy repositories to update even more often. And we don't want to let 'svn commit' do an auto-update of the working copy either. That's the job of 'svn update'. Changing the way mergeinfo is stored now would be a lot of work, and we might even use more properties in the future to give users more control over what Subversion is doing. So properties to manage meta-data will likely not go away. We can however improve performance (and we're already working on that). So let's assume for a moment that update took 1 nanosecond. Would that increase your productivity in an acceptable way, or would you still be put off by the fact that you need to run update after commit? And is this a big enough problem for your work flow that would make you switch to something else for version control? Thanks, Stefan
