SLOGEN <jensen@slog.dk> writes:
> C:\temp\wc\myproject>svn copy
> file:///c:/temp/svnroot/somelib/tags/1.0.1 somelib
> A somelib\file
> Checked out revision 9.
> A somelib
> C:\temp\wc\myproject>svn commit -m ""
> Adding myproject\somelib
> Committed revision 10.
Okay, so 'myproject/somelib' is now a copy of somelib/tags/1.0.1/.
You've committed that.
> How should i go about "upgrading" to a new version of "somelib" in
> "myproject", the obvious to try is:
What do you mean by 'upgrading'? You want somelib 1.0.2 to now be the
official version of the library in your project? If so, you probably
want to use 'svn merge' to compare 1.0.1 and 1.0.2 versions of the
library, and apply that patch to myproject/somelib/.
>
> C:\temp\wc\myproject>svn copy
> file:///c:/temp/svnroot/somelib/tags/1.0.2 somelib
> A somelib\1.0.2\file
> Checked out revision 10.
> A somelib\1.0.2
Nope, 'svn cp' doesn't overwrite directories. It creates a new
directory within the target directory, just like unix 'cp'.
> But that doesn't really produce the right result, so quickly:
>
> C:\temp\wc\myproject>svn del --force somelib/1.0.2
>
> When switching:
>
> C:\temp\wc\myproject>svn switch
> file:///c:/temp/svnroot/somelib/tags/1.0.2 somelib
> U somelib\file
> Updated to revision 10.
>
> SVN does not see this as a change to myproject, contrary to what I
> would expect. but instead as a switch in somelib:
>
> C:\temp\wc\myproject>svn status
> S somelib
>
> So SVN cannot commit that:
>
> C:\temp\wc\myproject>svn commit -m "now using somelib-1.0.2"
Correct. A switched subdirectory just means you've moved part of your
working copy to a branch: it's specific to your working copy. It has
no affect on your project in the repository.
> merge doese the right thing:
>
> C:\temp\wc\myproject>svn merge
> file:///c:/temp/svnroot/somelib/tags/1.0.1
> file:///c:/temp/svnroot/somelib/tags/1.0.2 somelib
> U somelib\file
> C:\temp\wc\myproject>svn commit -m "upgraded to somelib-1.0.2"
> Sending myproject\somelib\file
> Transmitting file data .
> Committed revision 11.
'svn merge' is the correct solution to your problem.
> But doesn't generate the right history:
>
> C:\temp\wc\myproject>svn log -v -r 11 .
> ------------------------------------------------------------------------
> rev 11: jensen | 2003-10-01 12:59:00 +0200 (Wed, 01 Oct 2003) | 1 line
> Changed paths:
> M /myproject/somelib/file
>
> upgraded to somelib-1.0.2
> ------------------------------------------------------------------------
>
> since I now lost track of where the content of somelib came from.
Line up behind the other 10,000 people waiting for this feature. :-)
Neither CVS or SVN remembers merge history. It's probably the single
largest, most anticipated post-1.0 feature right now.
> so im left with the workaround:
>
> C:\temp\wc\myproject>svn del --force somelib
> D somelib\file
> D somelib
> C:\temp\wc\myproject>svn commit -m "upgrading"
> Deleting myproject\somelib
> Committed revision 14.
> C:\temp\wc\myproject>svn copy
> file:///c:/temp/svnroot/somelib/tags/1.0.3 somelib
> A somelib\file
> Checked out revision 14.
> A somelib
>
> which is really not very satisfactory...
No, just use the 'svn merge' solution. In your log message, make a
note of the merge history manually. (Like, "merged revisions X
through Y of branch FOO into trunk", or "merged somelib 1.0.1 and
1.0.2 differences into myproject.".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 1 15:05:17 2003