On Wed, 2004-22-12 at 18:13 -0500, Joe wrote:
> 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
If I've got this right, the file `bar.php' does not exist in /trunk/ at
all.
Technically in your second choice I don't think you should have to run
`svn copy` since `svn merge` is more than just a patch program. It also
knows about changes to directory structures [aka additions and
deletions].
Reading this page should clear things up. Take note of the box titled
"Why Not Use Patches Instead?".
http://svnbook.red-bean.com/en/1.0/ch04s03.html
So as an experiment try to merge all the changes you made on the branch
into the trunk and see what happens. Make sure you have no local
changes in your working copy so you will not lose changes if you want to
do a `svn revert`. That is if things do not work out the way you would
like.
> 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.
No, I don't see it as an outlandish scenario. It's always good to know
where a file came from. Your commit message should say the file name
the new file is copied from and at what revision you took copied it as
well! That way it's easier to discover months from now when you have
forgot.
This is a repository policy decision that you need to make. There are
way more than one way to skin a cat but I think you are going about this
the correct way.
> 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
My opinion is no. It is the more difficult method (vi foo.php; :w
bar.php; svn commit bar.php; is easier, but you lose ancestry), but I
think you are getting more rewards by svn copy or svn merge.
It looks like you could have simply svn copy'd on the trunk without
making it in a different "branch" URL.
> 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.
I agree, I think you should keep the ancestry of the file.
You seem to have everything in order and a good start on the problem.
Let us know if you run into any more problems along the way.
HTH's
Chris
--
Software Engineering IV,
McMaster University
PGP Public Key: http://www.nesser.org/pgp-key/
19:20:39 up 1 day, 7:25, 3 users, load average: 0.35, 0.23, 0.12
http://www.fsf.org/philosophy/no-word-attachments.html
Received on Thu Dec 23 01:47:08 2004