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

Re: Is this possible in Subversion?

From: Paul T. Burba <ptbsvn_at_adelphia.net>
Date: 2006-11-16 21:27:58 CET

Mark Phippard wrote:
> Martin Marconcini wrote:
>> Hi Everybody,
>>
>> Today one of our developers (who comes from VSS) asked me a question
>> about svn and I have been unable to provide him with a decent answer;
>> I've been walking through google results and mailing list archives but
>> couldn't come up with a solution.
>>
>> I'll just say what he wants to do in case somebody has que same
>> question in mind:
>>
>> Is there such thing as "svn update --replace_existing_non_versioned" ?
>>
>> It is a file that already exists with the same name locally (is
>> unversioned) and you're bringing a new version from the repository. It
>> should ask "Replace Local" Yes/No.
>> The thing is: if the file is versioned and is locally, svn will merge
>> (or try at least), but if the file is not there, there's a file exist
>> conflict. He wants a way to --force the update to replace the local file.
>>
>> He showed me a VSS option called "REPLACE LOCAL" that does exactly
>> this. I couldn't come up with a simple solution (except from manually
>> deleteing the "should be replaced locally stored files" by hand.
>>
>> Any insight?
> This change has been implemented in trunk and thus will be part of 1.5.
> It either happens automatically, or you have to supply the --force
> parm. I cannot remember which was finally decided.

Currently in trunk you need to use --force. It's always possible that
could change by the time 1.5 is released, but for now it's not the
default behavior.

Paul B.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 16 21:29:57 2006

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.