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 Thu Aug 24 11:18:09 2006