On Fri, 20 Jul 2007, Ben Collins-Sussman wrote:
> 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.
Requiring --force to destroy, or a confirmation prompt like suggested
by glasser sounds fine too.
Either way, the ability to auto-confirm would be nice to have
(targeted at more experienced users).
> >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. :-)
Thanks Ben! Learn something new ever day.
- application/pgp-signature attachment: stored
Received on Fri Jul 20 20:10:02 2007