Christopher Ness wrote:
> What are the 3 versions again? I got lost along the way.
I was afraid of that :-) Let me try to explain better by providing a
more complete example:
$ svn import project file:///svn/repo -m "initial import"
Adding project/trunk
Adding project/trunk/foo.php
...
Committed revision 1.
$ svn checkout file:///svn/repo project
A project/foo.php
...
Checked out revision 1.
[additional changes made and committed to foo.php]
$ svn copy file:///svn/repo/trunk file:///svn/repo/branches/dev -m
"development branch"
Committed revision 5.
Additional changes were then made and merged to foo.php in both trunk
and branches/dev such that svn diff between the two at rev 9 shows a
single line difference--an extra error_reporting(E_ALL) in the
development code. Now we decide to create bar.php, which is very similar
to foo.php, so it seems like a good idea to copy foo.php and modify it.
$ cd [development working copy directory]
$ svn copy file:///svn/repo/branches/dev/foo.php bar.php
A bar.php
$ [edit bar.php]
$ svn commit
Adding bar.php
...
Committed revision 10.
Now svn log bar.php shows the ancestry of branches/dev/bar.php all the
way from the rev 1 import (as foo.php in trunk) through the branch in
rev 5 (-v shows "from /trunk:4") and to the addition in rev 10 (-v shows
"from /branches/dev/foo.php:9").
The question now is: Is it better to
$ cd [trunk working copy directory]
$ svn copy file:///svn/repo/branches/dev/bar.php bar.php
$ svn commit
OR
$ cd [trunk working copy directory]
$ svn copy file:///svn/repo/trunk/foo.php bar.php
$ svn merge ???
$ svn commit
The latter merge would apply to the trunk (working copy) bar.php the
same set of changes that were applied to branches/dev/foo.php@9 to
become branches/dev/bar.php@10. I haven't tried this option yet, so I'm
not sure about the syntax.
After the commit, say at rev 11, in the first case, bar.php would show
its "roundabout" ancestry, i.e., from trunk/foo.php to
branches/dev/foo.php to branches/dev/bar.php to trunk/bar.php. In the
second case, trunk/bar.php would only show trunk/foo.php as its
ancestor. On the surface, this simplified ancestry appears preferable
but I haven't explored all the implications and that's why I was seeking
guidance from others. I'm presuming, perhaps incorrectly, that this is
not such an outlandish scenario.
Would it have been better to create bar.php without letting Subversion
know about foo.php as its ancestor? As it is, the real foo.php and
bar.php files have about 450/460 lines each and a straight diff (not -u
or -c) has about 100 lines, so it seems reasonable to try to tie the two
together.
Regards,
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 23 00:16:46 2004