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

Re: [r25803] Interactively dealing with obstructed-addition conflicts

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-07-20 20:08:36 CEST

David Glasser wrote:
> On 7/20/07, Daniel Rall <dlr@collab.net> wrote:
>> I'm really hesitant to flat-out destroy the modified content in the
>> user's WC (choose_repos option), even upon their request. I can see
>> why an experienced user might want this behavior, but it's a definite
>> gotcha for the newbie who selects the wrong option without a full
>> understanding of the repercussions. Moving it aside into an
>> unversioned foo.discarded file seems like a safe -- if potentially
>> annoying -- behavior (possibly overridable in ~/.subversion/config?).
>
> Agreed. I believe it is currently the case that svn will never
> destroy unversioned data unless in the context of a command being run
> with '--force'.

Heh. I wish I could say the same of TortoiseSVN. Just this past Saturday,
I lost hours worth of recent work, and years of older documents deemed
interesting enough to keep but not version, when I mistakenly assumed that
TSVN's 'Delete' action behaved like 'svn rm', removing versioned items but
leaving unversioned or modified ones in a skeletal tree. Instead, it wiped
the whole tree. And I would have thought, being an Explorer shell
integration, that it made use of the Recycling Bin system. Nope -- no such
luck.

Data go bye-bye. C-Mike whimper.

[Stefan, are you listening?]

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Fri Jul 20 20:07:46 2007

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

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