You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by SLOGEN <je...@slog.dk> on 2003/10/01 11:10:31 UTC
replacing "svn copy"'ed dirs
SVN is working great for me, but I have some problems on how to re-copy
stuff.
When creating compositions in svn, using the "svn copy" command, like:
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.
How should i go about "upgrading" to a new version of "somelib" in
"myproject", the obvious to try is:
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
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"
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.
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.
(svn del ...; svn copy ...) is not good either, since, it cannot work as
an atomic transaction:
C:\temp\wc\myproject>svn del somelib
D somelib\file
D somelib
C:\temp\wc\myproject>svn copy
file:///c:/temp/svnroot/somelib/tags/1.0.3 somelib
A somelib\1.0.3\file
Checked out revision 13.
svn: Unmergeable scheduling requested on an entry
svn: Can not add 'somelib/1.0.3' to a parent directory scheduled for
deletion
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...
--
Helge
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: replacing "svn copy"'ed dirs
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Maybe we should file this bug. (Bugs?)
See issue 1516 "svn cp cannot replace schedule delete".
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: replacing "svn copy"'ed dirs
Posted by Ben Collins-Sussman <su...@collab.net>.
SLOGEN <je...@slog.dk> writes:
> The merge solution does a worse job than the "del; copy" solution. I
> really just want to assign somelib a new value, and that's what "del;
> copy" does (albeit not in an atomic step).
Ahh, I understand. If you want the history preserved using today's
code, 'del; copy' is definitely better. And you should absolutely be
able to do that as a single commit. It's called 'replacement'.
And yes, it looks like you found a real bug! The working copy is
supposed to understand 'replacement' already. For example, it works
fine for files:
$ svn rm iota
D iota
$ svn cp file:///home/sussman/scratch/repos/A/B/E/alpha iota
$ svn st
R + iota
$ svn ci -m "replacing iota with new file by same name"
Replacing iota
Committed revision 3.
But it fails for directory replacement:
$ svn rm A/D/G
D A/D/G/pi
D A/D/G/rho
D A/D/G/tau
D A/D/G
$ svn cp file:///home/sussman/scratch/repos/A/B/E A/D/G
A A/D/G/E/alpha
A A/D/G/E/beta
Checked out revision 3.
subversion/libsvn_wc/adm_ops.c:959: (apr_err=155013)
svn: Unmergeable scheduling requested on an entry
svn: Can not add 'A/D/G/E' to a parent directory scheduled for deletion
Notice that 'svn cp' syntax is biting us here. Because A/D/G still
exists, it's trying to create A/D/G/E.
But if I run
$ rm -rf A/D/G
Then I get the behavior I want:
$ svn cp file:///home/sussman/scratch/repos/A/B/E A/D/G
A A/D/G/alpha
A A/D/G/beta
Checked out revision 3.
A A/D/G
$ svn st
A + A/D/G
Unfortunately, our commit-driver seems to have a bug here. It tries
to add the new directory before deleting the old one!
$ svn ci -m "A/D/G is now a copy of A/B/E"
Adding A/D/G
subversion/libsvn_client/commit.c:727: (apr_err=160028)
svn: Transaction is out of date
svn: Commit failed (details follow):
subversion/libsvn_repos/commit.c:114: (apr_err=160028)
svn: out of date: '/A/D/G' in txn 'b'
Maybe we should file this bug. (Bugs?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: replacing "svn copy"'ed dirs
Posted by SLOGEN <je...@slog.dk>.
Ben Collins-Sussman wrote:
> SLOGEN <je...@slog.dk> writes:
Thanks for your reply, I value the efforts put into answering user
questions.
> 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/.
What i want is to replace the value of "somelib" in myproject with a new
value. There's really no reason for this to require a merge -- it's not
a merge, it's a replace.
>>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.
i respectfully disagree :)
>>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.
I'm not aiming/wishing for repeated merge, a simple "replace" with one
value of somelib for another would suffice.
Having the svn repository's history matching the actual actions I want
to do is a priority, it makes it _much_ easier to go back in
time/repos-space and see where the current source came from, no parsing
cryptic log messages involved :)
>>so im left with the workaround:
[ "del;copy" ]
>>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.".
The merge solution does a worse job than the "del; copy" solution. I
really just want to assign somelib a new value, and that's what "del;
copy" does (albeit not in an atomic step).
It seems like what's actually missing is a way to indicate whether
svn copy foo bar
should replace bar with foo, or add foo to the content of bar, the usual
problem with copy and path-syntax :)
BTW: I'm _not_ suggesting a tailing "/" to ditinguish between this, like
in rsync.
The above problems equally apply when tracking 3rd. party sources in svn.
Guess I'm gonna have to stick with the "del;copy" solution for a while.
--
Helge
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: replacing "svn copy"'ed dirs
Posted by Ben Collins-Sussman <su...@collab.net>.
SLOGEN <je...@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