[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Overwriting files.

From: Gavin Baumanis <gavinb_at_thespidernet.com>
Date: Fri, 29 May 2009 16:34:33 +1000

Hi Andrew,

On 28/05/2009, at 12:02 AM, Reedick, Andrew wrote:

> <snip>
>
>> And I have also used;
>> svn merge -r1:head trunk/ branches/vendor1/ - but that just seems
>> like
>> a bit of overkill - particularly if the trunk has seen a lot of
> action!
>>
>
> Why is it overkill? Run the merge. If there are any merge conflicts,
> always take the trunk version of the file (cp foo.java.right foo.java;
> svn resolve foo.java). Then check-in.
>

To me it just seemed like a lot of tree-walking for something that
should be (in my mind) a pretty simple task.
I would love a "--force" option for svn copy - that would seem to
simply provide what I need in this use-case.

Anyway,

> Something like:
> 1. svn merge...
>
> 2. Resolve the conflicts (I've always called this a copy-merge):
> svn status | grep '^C' | sed 's/^.......//' |
> while read i
> do
> cp "$i.right" "$i"
> svn resolve "$i"
> done
>
> 3. Then svn status to verify the workspace is clean
>
> 4. svn ci...
>

Nice... being new to the Mac (*nix) - I'm still coming to terms with
scripting and piping one command into another....
I quite like your solution here.

Again - it does seem like a relative expensive svn operation to do a
merge from r1 to head..

But it would certainly provide the correct outcome.
The vendor branch would indeed match the trunk and it would
appropriately "track" the history of how the vendor branch came to be
the way it is, now.

Thanks very much.

Gavin.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2356674

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-29 08:35:27 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.