>> What I'm asking is if this is reasonable functionality to add to the
merge
>> command. I don't mind passing a specific flag (like --force or
>> --allow-nonversioned) to enable this behavior.
>I think not. 'svn merge' is intended to take the changes between two
>*repository* trees and merge those changes into your working copy,
>whence you can then commit after (maybe) tweaking.
But the intent is the same - merge changes between two trees into my working
copy, which I can then commit after (maybe) tweaking. The only difference
is that one of the trees is unversioned.
>Merging automatically does schedule files for addition and deletion,
>as you would expect. But your use case is very different, not really
>something 'svn merge' was meant to address.
It doesn't seem very different to me -- it seems like a logical extension of
something svn already does. I could see the implementation possibly being a
difficult thing, but I'm willing to try and implement it myself. I just
want to know if there is such a fundamental disconnect between what merge
does and what I need that the new behavior doesn't belong in svn at all.
John C Barstow
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 19 23:34:24 2002