[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: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-07-20 20:01:05 CEST

On 7/20/07, Daniel Rall <dlr@collab.net> wrote:

> > + Dealing with obstruction of additions can be tricky. The
> > + obstructing item could be unversioned, versioned, or even
> > + schedule-add. Here's a matrix of how the caller should behave,
> > + based on results we return.
> > +
> > + Unversioned Versioned Schedule-Add
> > +
> > + choose_user skip addition, skip addition skip addition
> > + add existing item
> > +
> > + choose_repos destroy file, schedule-delete, revert add,
> > + add new item. add new item. rm file,
> > + add new item
> 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?).

I'm okay with just moving it out of the way, rather than destroying
it. Does anyone else have an opinion on this?

> I hadn't realized that it was possible to have a pending schedule of
> "delete, then add" on the same path within a WC. I guess this has
> been needed to support uncommitted overwrites in a WC?

Sure, try it now: do an 'svn rm foo; touch foo; svn add foo'.
You'll see that 'svn status' says that the foo is scheduled for
(R)eplacement. This feature is as old as the hills. :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 20 20:00:12 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.