Re: replacing "svn copy"'ed dirs

Ben Collins-Sussman wrote:
> SLOGEN <jensen@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