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