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
Received on 2010-04-06 00:02:10 CEST