You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2007/05/09 20:44:52 UTC
merge-tracking -- getting my feet wet
Hi guys, I'm trying to figger out what our merge-tracking code is and
isn't capable of. I'm also starting to work on making our
notification system deal with 'multiple notifications' of subsequently
merged ranges of revisions.
Just to get my feet wet, I wrote a short shell script. The script
does a bunch of commits to a branch. It cherrypicks one change and
ports it from branch to trunk, then tries to just 'merge everything
else' by magic (svn merge BRANCHURL trunk-wc).
My expectation is that the magic-merge should do merge two distinct
ranges of changes -- those before my cherrypicked change, and those
after. However, my output is bizarre... lots of additions, conflicts,
and so on. I need a sanity check, or a does of expectation
management. :-)
Script and output are attached below.
--------
#!/bin/sh
TRUNKURL=file://`pwd`/mergerepos/trunk
BRANCHURL=file://`pwd`/mergerepos/trunk
# Create populated repos
rm -rf mergerepos
svnadmin create mergerepos
svn mkdir $TRUNKURL -m "make trunk" # r1
svn import zvm-test-data $TRUNKURL -m "import code" # r2
# Branch the trunk
svn cp $TRUNKURL $BRANCHURL -m "make branch" # r3
# Grab a WC of branch and trunk each
rm -rf trunk-wc branch-wc
svn co $TRUNKURL trunk-wc
svn co $BRANCHURL branch-wc
# Make some commits to branch
echo "blah" >> branch-wc/zcpu.py
svn commit branch-wc -m "change zcpu." # r4
echo "glorb" >> branch-wc/zmachine.py
svn commit branch-wc -m "change zmachine." # r5
echo "narf" >> branch-wc/zstring.py
svn commit branch-wc -m "change zstring." # r6
# Merge just one cherrypicked change to the trunk
svn up trunk-wc
svn merge -c5 $BRANCHURL trunk-wc
svn commit trunk-wc -m "port one change to trunk". # r7
# Now merge 'the rest' of the branch changes to the trunk.
# Merge tracking should magically know to merge the two ranges (r4 and r6)
svn up trunk-wc
svn merge $BRANCHURL trunk-wc
--------
Committed revision 1.
Adding zvm-test-data/zlexer.py
Adding zvm-test-data/zstackmanager.py
Adding zvm-test-data/ziomanager.py
Adding zvm-test-data/zobjectparser.py
Adding zvm-test-data/glk.py
Adding zvm-test-data/zopdecoder.py
Adding zvm-test-data/zmachine.py
Adding zvm-test-data/__init__.py
Adding zvm-test-data/zstring.py
Adding zvm-test-data/zcpu.py
Adding zvm-test-data/bitfield.py
Adding zvm-test-data/zmemory.py
Adding zvm-test-data/quetzal.py
Adding zvm-test-data/zui.py
Committed revision 2.
Committed revision 3.
A trunk-wc/zlexer.py
A trunk-wc/zstackmanager.py
A trunk-wc/trunk
A trunk-wc/trunk/zlexer.py
A trunk-wc/trunk/zstackmanager.py
A trunk-wc/trunk/ziomanager.py
A trunk-wc/trunk/glk.py
A trunk-wc/trunk/zobjectparser.py
A trunk-wc/trunk/zmachine.py
A trunk-wc/trunk/zopdecoder.py
A trunk-wc/trunk/__init__.py
A trunk-wc/trunk/zstring.py
A trunk-wc/trunk/zcpu.py
A trunk-wc/trunk/bitfield.py
A trunk-wc/trunk/zmemory.py
A trunk-wc/trunk/quetzal.py
A trunk-wc/trunk/zui.py
A trunk-wc/ziomanager.py
A trunk-wc/glk.py
A trunk-wc/zobjectparser.py
A trunk-wc/zmachine.py
A trunk-wc/zopdecoder.py
A trunk-wc/__init__.py
A trunk-wc/zstring.py
A trunk-wc/zcpu.py
A trunk-wc/bitfield.py
A trunk-wc/zmemory.py
A trunk-wc/quetzal.py
A trunk-wc/zui.py
Checked out revision 3.
A branch-wc/zlexer.py
A branch-wc/zstackmanager.py
A branch-wc/trunk
A branch-wc/trunk/zlexer.py
A branch-wc/trunk/zstackmanager.py
A branch-wc/trunk/ziomanager.py
A branch-wc/trunk/glk.py
A branch-wc/trunk/zobjectparser.py
A branch-wc/trunk/zmachine.py
A branch-wc/trunk/zopdecoder.py
A branch-wc/trunk/__init__.py
A branch-wc/trunk/zstring.py
A branch-wc/trunk/zcpu.py
A branch-wc/trunk/bitfield.py
A branch-wc/trunk/zmemory.py
A branch-wc/trunk/quetzal.py
A branch-wc/trunk/zui.py
A branch-wc/ziomanager.py
A branch-wc/glk.py
A branch-wc/zobjectparser.py
A branch-wc/zmachine.py
A branch-wc/zopdecoder.py
A branch-wc/__init__.py
A branch-wc/zstring.py
A branch-wc/zcpu.py
A branch-wc/bitfield.py
A branch-wc/zmemory.py
A branch-wc/quetzal.py
A branch-wc/zui.py
Checked out revision 3.
Sending branch-wc/zcpu.py
Transmitting file data .
Committed revision 4.
Sending branch-wc/zmachine.py
Transmitting file data .
Committed revision 5.
Sending branch-wc/zstring.py
Transmitting file data .
Committed revision 6.
U trunk-wc/zmachine.py
U trunk-wc/zstring.py
U trunk-wc/zcpu.py
Updated to revision 6.
Sending trunk-wc
Sending trunk-wc/trunk
Committed revision 7.
At revision 7.
G trunk-wc/trunk
A trunk-wc/zlexer.py
A trunk-wc/zstackmanager.py
A trunk-wc/ziomanager.py
A trunk-wc/glk.py
A trunk-wc/zobjectparser.py
C trunk-wc/zmachine.py
A trunk-wc/zopdecoder.py
A trunk-wc/__init__.py
C trunk-wc/zstring.py
A trunk-wc/zcpu.py
A trunk-wc/bitfield.py
A trunk-wc/zmemory.py
A trunk-wc/quetzal.py
A trunk-wc/zui.py
C trunk-wc/zstring.py
G trunk-wc
$ svn st trunk-wc/
M trunk-wc
? trunk-wc/zmachine.py.merge-right.r4
? trunk-wc/zstring.py.merge-right.r4
? trunk-wc/zstring.py.merge-right.r7
? trunk-wc/zmachine.py.merge-left.r0
? trunk-wc/zstring.py.merge-left.r0
? trunk-wc/zstring.py.merge-left.r5
? trunk-wc/zmachine.py.working
? trunk-wc/zstring.py.working
? trunk-wc/zstring.py.2.working
C trunk-wc/zmachine.py
C trunk-wc/zstring.py
M trunk-wc/trunk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge-tracking -- getting my feet wet
Posted by Norbert Unterberg <nu...@gmail.com>.
2007/5/10, Ben Collins-Sussman <su...@red-bean.com>:
> Subversion hasn't yet ever used 'changeset' as part of its official
> vocabulary. If you look at the description of the '-c' option, it's
> just called 'change', and is short for -rN-1:N. If we want to stay
> in the current Subversion universe, we would use the term 'revision'
> to refer to both a tree and a changeset, depending on context. :-)
I recently ran into some problems because "-cN" should not be the same
as "-rN-1:N" in some real-world scenarios. It is the same if you look
at the complete repository, but can make a difference when you deal
with branches.
Example:
create repo structure with trunk and branches folder, and a file in trunk --> r1
checkout trunk into two different WC: wc1 and wc2
change file in wc1 and commit --> r2
change file in wc2 and create branch from wc2 --> r3
switch wc2 to the new branch
A "svn diff -c3 wc2" fails with
"svn: Unable to find repository location for 'wc2' in revision 2"
I think this is because -c3 expands to -r2:3. r2 is not the ancestor
of wc2@3, but r1 is. A svn diff -r1:3 wc2 succeeds.
Shouldn't Subversion use some kind of history tracking when called
with -cN? At least people should stop telling users that -rN-1:N gives
the change that lead to rN, because it does so only in most cases, but
not in the general case.
Well, this has nothing to do with merge tracking, but I could not
resist. Or wait, how would merge tracking hande this case when you
merge branch back to trunk?
Complete reproduction script (for windows, svn 1.4.3, renamed due to
Gmail limtations) attached.
Norbert
Re: merge-tracking -- getting my feet wet
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Subversion hasn't yet ever used 'changeset' as part of its official
vocabulary. If you look at the description of the '-c' option, it's
just called 'change', and is short for -rN-1:N. If we want to stay
in the current Subversion universe, we would use the term 'revision'
to refer to both a tree and a changeset, depending on context. :-)
On 5/10/07, Michael Brouwer <mb...@gmail.com> wrote:
> Warning possible bikeshed ahead,
>
> Rather than revision should you maybe use the term change or changeset?
> After all a revision is a snapshot of the tree, whereas a changeset are the
> changes between that revision and it's predecessor (at least if I remember
> the discussion about the -c option correctly.
>
> --- Merging changeset 4 to 'trunk-wc':
> U trunk-wc/zcpu.py
> --- Merging changesets 6-7 to 'trunk-wc':
> U trunk-wc/zstring.py
>
> Michael
>
>
> On 5/10/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> >
> > On 5/10/07, John Peacock <jp...@rowman.com> wrote:
> > > Ben Collins-Sussman wrote:
> > > > Ah, that explains my confusion. These aren't endpoints being compared
> > > > with each other, as in typical 'svn merge' or 'svn diff' invocations.
> > > > You're saying that an svn_merge_range_t is just a *list* of revisions
> > > > to merge?
> > >
> > > And if _you_ are confused, think about the random user who has no idea
> > > what is going on internally. This is inconsistent with every other
> > > merge-like operation, so I think this may call for a redesign (at least
> > > of the user interface). Is it sufficient to say display (r-1):r (where
> > > svn_merge_range_t contains just r)?
> >
> > I'm already ahead of you. :-) I just changed the UI to display this
> instead:
> >
> > --- Merging revision 4 to 'trunk-wc':
> > U trunk-wc/zcpu.py
> > --- Merging revisions 6-7 to 'trunk-wc':
> > U trunk-wc/zstring.py
> >
> > In other words, we're claiming to merge 'lists of revisions', rather
> > than showing our -rX:Y comparison syntax. I think that will prevent
> > the confusion.
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge-tracking -- getting my feet wet
Posted by Michael Brouwer <mb...@gmail.com>.
Warning possible bikeshed ahead,
Rather than revision should you maybe use the term change or changeset?
After all a revision is a snapshot of the tree, whereas a changeset are the
changes between that revision and it's predecessor (at least if I remember
the discussion about the -c option correctly.
--- Merging changeset 4 to 'trunk-wc':
U trunk-wc/zcpu.py
--- Merging changesets 6-7 to 'trunk-wc':
U trunk-wc/zstring.py
Michael
On 5/10/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
>
> On 5/10/07, John Peacock <jp...@rowman.com> wrote:
> > Ben Collins-Sussman wrote:
> > > Ah, that explains my confusion. These aren't endpoints being compared
> > > with each other, as in typical 'svn merge' or 'svn diff' invocations.
> > > You're saying that an svn_merge_range_t is just a *list* of revisions
> > > to merge?
> >
> > And if _you_ are confused, think about the random user who has no idea
> > what is going on internally. This is inconsistent with every other
> > merge-like operation, so I think this may call for a redesign (at least
> > of the user interface). Is it sufficient to say display (r-1):r (where
> > svn_merge_range_t contains just r)?
>
> I'm already ahead of you. :-) I just changed the UI to display this
> instead:
>
> --- Merging revision 4 to 'trunk-wc':
> U trunk-wc/zcpu.py
> --- Merging revisions 6-7 to 'trunk-wc':
> U trunk-wc/zstring.py
>
> In other words, we're claiming to merge 'lists of revisions', rather
> than showing our -rX:Y comparison syntax. I think that will prevent
> the confusion.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: merge-tracking -- getting my feet wet
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 5/10/07, John Peacock <jp...@rowman.com> wrote:
> Ben Collins-Sussman wrote:
> > Ah, that explains my confusion. These aren't endpoints being compared
> > with each other, as in typical 'svn merge' or 'svn diff' invocations.
> > You're saying that an svn_merge_range_t is just a *list* of revisions
> > to merge?
>
> And if _you_ are confused, think about the random user who has no idea
> what is going on internally. This is inconsistent with every other
> merge-like operation, so I think this may call for a redesign (at least
> of the user interface). Is it sufficient to say display (r-1):r (where
> svn_merge_range_t contains just r)?
I'm already ahead of you. :-) I just changed the UI to display this instead:
--- Merging revision 4 to 'trunk-wc':
U trunk-wc/zcpu.py
--- Merging revisions 6-7 to 'trunk-wc':
U trunk-wc/zstring.py
In other words, we're claiming to merge 'lists of revisions', rather
than showing our -rX:Y comparison syntax. I think that will prevent
the confusion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge-tracking -- getting my feet wet
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> Ah, that explains my confusion. These aren't endpoints being compared
> with each other, as in typical 'svn merge' or 'svn diff' invocations.
> You're saying that an svn_merge_range_t is just a *list* of revisions
> to merge?
And if _you_ are confused, think about the random user who has no idea
what is going on internally. This is inconsistent with every other
merge-like operation, so I think this may call for a redesign (at least
of the user interface). Is it sufficient to say display (r-1):r (where
svn_merge_range_t contains just r)?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge-tracking -- getting my feet wet
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 5/10/07, Mark Phippard <ma...@gmail.com> wrote:
> r4
> r6 through HEAD.
Yes, that's what I see; a range r4 - r4, and a range r6 - r7.
>
> I am assuming HEAD == r7
Yes, that's correct.
>
> Furthermore, my "ranges" are expressing the revisions that are being
> merged, not the typical N-1 range you would give the command.
Ah, that explains my confusion. These aren't endpoints being compared
with each other, as in typical 'svn merge' or 'svn diff' invocations.
You're saying that an svn_merge_range_t is just a *list* of revisions
to merge?
That makes sense to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge-tracking -- getting my feet wet
Posted by Mark Phippard <ma...@gmail.com>.
On 5/10/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> I've extended the notification system to show multiple merges
> happening. Something like this:
>
> --- Merging r4 to 'trunk-wc':
> U trunk-wc/zcpu.py
> --- Merging r6:r7 to 'trunk-wc':
> U trunk-wc/zstring.py
>
> There's something odd going on, though. My test script does 3 commits
> to the branch (r4, r5, r6). I then port r5 to the trunk and commit,
> and finally let the 'magic' merge figure out the remaining ranges by
> doing 'svn merge branchURL trunk-wc'.
>
> The merge code should detect two ranges to merge: r4 and r6. But the
> svn_merge_range_t's it generates are weird: one is 'r4:r4', and the
> other is 'r6:r7'. The thing is, the correct changes seem to be ported
> anyway.
>
> Shouldn't the first range be 'r3:r4'? Why is r4:r4 behaving like r3:r4?
> Shouldn't the second range be 'r5:r6'? Why is r6:r7 behaving like r5:r6?
Based on your description, I would expect to see two "ranges" merged:
r4
r6 through HEAD.
I am assuming HEAD == r7
Furthermore, my "ranges" are expressing the revisions that are being
merged, not the typical N-1 range you would give the command.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge-tracking -- getting my feet wet
Posted by Ben Collins-Sussman <su...@red-bean.com>.
I've extended the notification system to show multiple merges
happening. Something like this:
--- Merging r4 to 'trunk-wc':
U trunk-wc/zcpu.py
--- Merging r6:r7 to 'trunk-wc':
U trunk-wc/zstring.py
There's something odd going on, though. My test script does 3 commits
to the branch (r4, r5, r6). I then port r5 to the trunk and commit,
and finally let the 'magic' merge figure out the remaining ranges by
doing 'svn merge branchURL trunk-wc'.
The merge code should detect two ranges to merge: r4 and r6. But the
svn_merge_range_t's it generates are weird: one is 'r4:r4', and the
other is 'r6:r7'. The thing is, the correct changes seem to be ported
anyway.
Shouldn't the first range be 'r3:r4'? Why is r4:r4 behaving like r3:r4?
Shouldn't the second range be 'r5:r6'? Why is r6:r7 behaving like r5:r6?
On 5/9/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> Ahhhhhhhhhhhh, thank you. I knew I needed another pair of eyes.
>
> What would be great is if some sort of... notification system... were
> to say helpful things like "I'm merging this revision range from URL
> to TARGET". :-)
>
> *cough*
>
> On 5/9/07, Daniel Rall <dl...@collab.net> wrote:
> > Ben, there's a bug in your test:
> >
> > TRUNKURL=file://`pwd`/mergerepos/trunk
> > BRANCHURL=file://`pwd`/mergerepos/trunk
> > ^^^^^
> >
> > If I use:
> >
> > BRANCHURL=file://`pwd`/mergerepos/branch
> >
> > ...things work as expected.
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge-tracking -- getting my feet wet
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Ahhhhhhhhhhhh, thank you. I knew I needed another pair of eyes.
What would be great is if some sort of... notification system... were
to say helpful things like "I'm merging this revision range from URL
to TARGET". :-)
*cough*
On 5/9/07, Daniel Rall <dl...@collab.net> wrote:
> Ben, there's a bug in your test:
>
> TRUNKURL=file://`pwd`/mergerepos/trunk
> BRANCHURL=file://`pwd`/mergerepos/trunk
> ^^^^^
>
> If I use:
>
> BRANCHURL=file://`pwd`/mergerepos/branch
>
> ...things work as expected.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merge-tracking -- getting my feet wet
Posted by Daniel Rall <dl...@collab.net>.
Ben, there's a bug in your test:
TRUNKURL=file://`pwd`/mergerepos/trunk
BRANCHURL=file://`pwd`/mergerepos/trunk
^^^^^
If I use:
BRANCHURL=file://`pwd`/mergerepos/branch
...things work as expected.
Re: merge-tracking -- getting my feet wet
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 09 May 2007, Ben Collins-Sussman wrote:
> Hi guys, I'm trying to figger out what our merge-tracking code is and
> isn't capable of. I'm also starting to work on making our
> notification system deal with 'multiple notifications' of subsequently
> merged ranges of revisions.
This is expected to work. I'm also seeing weird output from your test
case.
> Just to get my feet wet, I wrote a short shell script. The script
> does a bunch of commits to a branch. It cherrypicks one change and
> ports it from branch to trunk, then tries to just 'merge everything
> else' by magic (svn merge BRANCHURL trunk-wc).
>
> My expectation is that the magic-merge should do merge two distinct
> ranges of changes -- those before my cherrypicked change, and those
> after. However, my output is bizarre... lots of additions, conflicts,
> and so on. I need a sanity check, or a does of expectation
> management. :-)
Your expectation is correct. I see do_merge() calculating the correct
revision range. However, something is going wonky. I noticed that
their appears to be merge info in the tree below the level of the
merge (so-called "sub-tree merge info"); I wonder if that is
responsible...
- Dan