[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Evil twin bug ?

From: Lakshman Srilakshmanan <lakshman.srilakshmanan_at_tradingpost.com.au>
Date: 2006-08-24 10:02:33 CEST

Hi Ryan,

Thanks for your feedback.

Firstly
-------
scmop@maggie:~/sgs-trunk > svn merge -rA1:A2
svn://lakshman@maggie/sgs/branches/ProjectA

The above command is not practical when ProjectA is a long running
branch (ie enhancement/refactoring). The reason being changes/fixes are
committed into trunk before every release into production. These changes
are merged into ProjectA on a regular basis to ensure that ProjectA has
all the changes/fixes that have gone into production.

When merging ProjectA into trunk, if we assume A1 as start of branch and
A2 as the head, we will get heaps of conflicts because of the merges
that have come from trunk. The alternative is to exclude the revisions
that formed the merges from trunk. There will be many revisions to
exclude with a huge room for error.

svn merge svn://lakshman@maggie/sgs/trunk
svn://lakshman@maggie/sgs/branches/ProjectA

Therefore, to answer your question, the above url will construct a list
of steps that turn the trunk into Project A. These steps will contain
only the changes made in ProjectA.

Secondly
--------

If a file was added to ProjectA and ProjectB merged it from ProjectA
then we will not have the problem I have outline below. In fact, the
merging pattern I have outline above works very nicely. I believe, the
reason for this is because subversion identifies the file as having an
Ancestry and is able to merge it successfully.

Finally
-------
The reason we get an Out of Date error is because the Revision Number
after the merge is _zero_. Hence it is an older revision to the copy in
subversion. (mystery solved).

Conclusion
----------
The actual problem in this issue is that we have added the same file
twice (Evil twin). Thus creating two instances with different identities
for the same name.

There is no problem in what Subversion is trying to do. It is attempting
to keep the target version and discarding the existing version in the
second merge process(ref to Andrew Reedicks email earlier).

The problem is, in attempting to keep the target version it corrupts the
Revision number in the working copy, causing the Out of Date error. This
I believe is a bug. Either Subversion should use the target version or
create a conflict and allow the user to resolve it.

So, to anyone who has been following this email trail and not gone to
sleep, I open this discussion to determine if this is a bug/or not.

Thanks
Lakshman

> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2006c@ryandesign.com]
> Sent: Thursday, 24 August 2006 5:17 PM
> To: Lakshman Srilakshmanan
> Cc: users@subversion.tigris.org; Andrew.Reedick@bellsouth.com
> Subject: Re: Evil twin bug ?
>
> On Aug 24, 2006, at 06:55, Lakshman Srilakshmanan wrote:
>
> > I appear to have a problem with merging Evil twins in Subversion. I
> > have
> > outlined the scenario below.
> >
> > Could you please review it and inform me whether this is a bug or
not,
> > if it is bug then whether it has been raised as a bug ?
> >
> > Overview
> > --------
> > /branches
> > /ProjectA
> > /ProjectB
> > /tags
> > /trunk
> >
> > Scenario
> > --------
> > Step 1 -- Add files into Project A
> >
> > Step 2 -- Add files into Project B
> >
> > Step 3 -- Merge Project A into trunk and commit
> >
> > Validate files
> >
> > Step 4 -- Merge Project B into trunk
> >
> > Validate files (Note how the Revision numbers are zero)
> >
> > Step 5 -- Commit files into trunk (Out of date) error
> >
> >
> > Step 1 -- Add files into Project A
> > ------------------------------------------------
> > scmop@maggie:~/ProjectA > svn add *
> > A (bin) logo_tp.gif
> > A NantExample.build
> > scmop@maggie:~/ProjectA > svn commit *
> > Adding NantExample.build
> > Adding (bin) logo_tp.gif
> > Transmitting file data ..
> > Committed revision 6.
> >
> >
> > Step 2 -- Add files into Project B
> > ------------------------------------------------
> > scmop@maggie:~/ProjectB > svn add *
> > A (bin) logo_tp.gif
> > A NantExample.build
> > scmop@maggie:~/ProjectB > svn commit
> > Adding NantExample.build
> > Adding (bin) logo_tp.gif
> > Transmitting file data ..
> > Committed revision 7.
> >
> >
> > Step 3 -- Merge Project A into trunk
> > ------------------------------------
> > scmop_at_maggie:~/sgs-trunk > svn merge svn://lakshman@maggie/sgs/trunk
> > svn://lakshman@maggie/sgs/branches/ProjectA
> > A logo_tp.gif
> > A NantExample.build
> > scmop@maggie:~/sgs-trunk > svn commit
> > Adding NantExample.build
> > Adding (bin) logo_tp.gif
>
> That's not how you merge Project A into trunk. You've asked
> Subversion to construct a list of steps that turn the trunk into
> Project A, and to perform those steps on the working copy of trunk.
> If trunk and Project A are identical except for the changes you've
> made in Project A, then this will seem to work fine, but if there are
> any other changes in trunk that were not made in Project A, those
> changes will be *undone* by the above merge, which is probably not
> what you wanted. Instead, you should ask Subversion to construct a
> list of steps that transform Project A at its inception into Project
> A as it exists now, and perform those in the trunk working copy.
>
> scmop_at_maggie:~/sgs-trunk > svn merge -rA1:A2 svn://lakshman@maggie/
> sgs/branches/ProjectA
>
> where A1 is the revision at which the branch was created, and A2 is
> the current revision. Since Subversion offers no merge tracking yet,
> you must manually keep track of A1 and A2, and ensure that you don't
> try to merge the same revisions more than once.
>
>
> > Validate files
> > --------------
> > scmop@maggie:~/sgs-trunk > svn info NantExample.build
> > Path: NantExample.build
> > Name: NantExample.build
> > URL: svn://lakshman@maggie/sgs/trunk/NantExample.build
> > Repository Root: svn://lakshman@maggie/sgs
> > Repository UUID: 298f41a3-bb1b-0410-bb7a-81c08510be87
> > Revision: 8
> > Node Kind: file
> > Schedule: normal
> > Last Changed Author: lakshman
> > Last Changed Rev: 8
> > Last Changed Date: 2006-08-24 14:29:14 +1000 (Thu, 24 Aug 2006)
> > Text Last Updated: 2006-08-24 14:28:58 +1000 (Thu, 24 Aug 2006)
> > Properties Last Updated: 2006-08-24 14:28:58 +1000 (Thu, 24 Aug
2006)
> > Checksum: 7bcd34d20526838ccc4eb46921093972
> >
> > scmop@maggie:~/sgs-trunk > svn info logo_tp.gif
> > Path: logo_tp.gif
> > Name: logo_tp.gif
> > URL: svn://lakshman@maggie/sgs/trunk/logo_tp.gif
> > Repository Root: svn://lakshman@maggie/sgs
> > Repository UUID: 298f41a3-bb1b-0410-bb7a-81c08510be87
> > Revision: 8
> > Node Kind: file
> > Schedule: normal
> > Last Changed Author: lakshman
> > Last Changed Rev: 8
> > Last Changed Date: 2006-08-24 14:29:14 +1000 (Thu, 24 Aug 2006)
> > Text Last Updated: 2006-08-24 14:28:58 +1000 (Thu, 24 Aug 2006)
> > Properties Last Updated: 2006-08-24 14:28:58 +1000 (Thu, 24 Aug
2006)
> > Checksum: efd57e540094bb6d9c211eed5f1e7e31
> >
> >
> > Step 4 -- Merge Project B into trunk
> > ------------------------------------
> > scmop_at_maggie:~/sgs-trunk > svn merge svn://lakshman@maggie/sgs/trunk
> > svn://lakshman@maggie/sgs/branches/ProjectB
> > D logo_tp.gif
> > A logo_tp.gif
> > D NantExample.build
> > A NantExample.build
>
> Same here. You've asked to transform trunk (with is now the same as
> Project A) into Project B, so you see it's deleting the files that
> had been added from Project A, and replacing them with those from
> Project B. Again, you need to merge just the revisions from Project B
> that you want:
>
> scmop_at_maggie:~/sgs-trunk > svn merge -rB1:B2 svn://lakshman@maggie/
> sgs/branches/ProjectB
>
>
> > Validate files
> > --------------
> > scmop@maggie:~/sgs-trunk > svn info NantExample.build
> > Path: NantExample.build
> > Name: NantExample.build
> > URL: svn://lakshman@maggie/sgs/trunk/NantExample.build
> > Repository Root: svn://lakshman@maggie/sgs
> > Revision: 0
> > Node Kind: file
> > Schedule: replace
>
> > Copied From URL:
> > svn://lakshman@maggie/sgs/branches/ProjectB/NantExample.build
> > Copied From Rev: 8
> > Last Changed Author: lakshman
> > Last Changed Rev: 7
> > Last Changed Date: 2006-08-24 14:27:18 +1000 (Thu, 24 Aug 2006)
> > Text Last Updated: 2006-08-24 14:31:37 +1000 (Thu, 24 Aug 2006)
> > Properties Last Updated: 2006-08-24 14:31:37 +1000 (Thu, 24 Aug
2006)
> > Checksum: 7bcd34d20526838ccc4eb46921093972
> >
> > scmop@maggie:~/sgs-trunk > svn info logo_tp.gif
> > Path: logo_tp.gif
> > Name: logo_tp.gif
> > URL: svn://lakshman@maggie/sgs/trunk/logo_tp.gif
> > Repository Root: svn://lakshman@maggie/sgs
> > Revision: 0
> > Node Kind: file
> > Schedule: replace
> > Copied From URL: svn://lakshman@maggie/sgs/branches/ProjectB/
> > logo_tp.gif
> > Copied From Rev: 8
> > Last Changed Author: lakshman
> > Last Changed Rev: 7
> > Last Changed Date: 2006-08-24 14:27:18 +1000 (Thu, 24 Aug 2006)
> > Text Last Updated: 2006-08-24 14:31:37 +1000 (Thu, 24 Aug 2006)
> > Properties Last Updated: 2006-08-24 14:31:37 +1000 (Thu, 24 Aug
2006)
> > Checksum: efd57e540094bb6d9c211eed5f1e7e31
> >
> > Step 5 -- Commit files into trunk
> > ---------------------------------
> > scmop@maggie:~/sgs-trunk > svn commit
> > Replacing NantExample.build
> > Replacing logo_tp.gif
> > svn: Commit failed (details follow):
> > svn: Out of date: '/trunk/NantExample.build' in transaction '8-1'
> > svn: Your commit message was left in a temporary file:
> > svn: '/home/scmop/sgs-trunk/svn-commit.tmp'
>
> In the end, I'm not in fact sure why there's an out-of-date error
> here. But the commands you're issuing do not correspond to the
> actions you want to perform, so I'd fix that first, then see where
> that leaves you.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 24 10:38:05 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.