Hi Ryan,
> Whether it's impractical or not, it's how Subversion currently works.
> You must manually keep track of which revisions you have merged. As
> you point out, you should not always have A1 as the start of the
> branch. The first time you merge to trunk, A1 should be the start of
> the A branch (let's call it 10), and A2 should be the current
> revision (let's call it 23). So you merge -r10:23 of project A into
> trunk. You should say exactly that in your commit message. ("Merged
> r10-23 of project A into trunk.") The next time you want to merge,
> you would start at the last revision you merged (23) and go again to
> the current head (let's say now it's 42). So you'd merge -r23:42. And
> so on.
>
> The fact that it's inconvenient to remember all this means that a)
> you should record it in the log message so you can look it up if you
> forget, b) work is progressing on a way for Subversion to
> automatically track this info (it's called "merge tracking"), and c)
> there is a Python script svnmerge.py you can use today that attempts
> to do this for you, which you could try. But before you do, it's
> essential to understand how merging works, as I described above.
It is not just a question of recording comments and using comments to
track merge manually. Where human intervention is involved there is room
for error. This is synonymous to saying "Why use Subversion rollback ie
(merge -r30:28)", if your record your changes then you can do this
manually. You, I and everyone knows that doing rollback manually is hard
and error prone, and I must admit Subversion does this magnificently.
But I do take your point I could use " Python script svnmerge.py". I
made a conscious decision not to use this as I read on this user forum
that it is not endorsed by the custodians of Subversion. I would rather
wait for subversion to have a supported feature than introduce a third
party tool that is not supported by CollabNet.
> > 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.
>
> and will *undo* any changes that had been made in trunk but not in
> Project A. Be sure you understand that.
The above step will *not undo* any changes that had been made in trunk
because the process I established in our organisation was to merge from
trunk immediately (to ensure no changes) before attempting a merge from
branch into trunk. Therefore the branch will definitely have all changes
from trunk. We don't use "HEAD" we identify the revision number for
"HEAD" and use that. This avoids any nasty surprises.
Thanks
Lakshman
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2006c@ryandesign.com]
> Sent: Thursday, 24 August 2006 7:17 PM
> To: Lakshman Srilakshmanan
> Cc: Andrew.Reedick@bellsouth.com; users@subversion.tigris.org
> Subject: Re: Evil twin bug ?
>
>
> On Aug 24, 2006, at 10:02, Lakshman Srilakshmanan wrote:
>
> > 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.
>
> Whether it's impractical or not, it's how Subversion currently works.
> You must manually keep track of which revisions you have merged. As
> you point out, you should not always have A1 as the start of the
> branch. The first time you merge to trunk, A1 should be the start of
> the A branch (let's call it 10), and A2 should be the current
> revision (let's call it 23). So you merge -r10:23 of project A into
> trunk. You should say exactly that in your commit message. ("Merged
> r10-23 of project A into trunk.") The next time you want to merge,
> you would start at the last revision you merged (23) and go again to
> the current head (let's say now it's 42). So you'd merge -r23:42. And
> so on.
>
> The fact that it's inconvenient to remember all this means that a)
> you should record it in the log message so you can look it up if you
> forget, b) work is progressing on a way for Subversion to
> automatically track this info (it's called "merge tracking"), and c)
> there is a Python script svnmerge.py you can use today that attempts
> to do this for you, which you could try. But before you do, it's
> essential to understand how merging works, as I described above.
>
>
> > 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.
>
> and will *undo* any changes that had been made in trunk but not in
> Project A. Be sure you understand that.
>
>
> > 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).
>
> I can't comment on that.
>
>
> > 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.
>
> Yes, I would agree, that is a problem, and should have been avoided.
>
>
> > 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.
>
> I have no comment here.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 25 03:10:20 2006