I've been following this conversation and decided to share some possible
options from other tools.
In Telelogic's CM Synergy, there were two commands that developers would
improperly interchange with some frequency: add and create. The 'create'
command would create an entry in the database for a new file *and* add a
reference in the user's project (Synergy term for repository); in
contrast, the 'add' command simply added a reference in the user's project
to a file that already existed in the database. There was also an 'unuse'
command that was temporary until the next update.
Following the logic of these terms, the opposites would be 'subtract' to
remove a reference to a file from a project, and 'destroy' to completely
obliterate the file from the database. I think the connotation of the
latter could act as a good deterrent from the accidental shooting of feet.
I'm currently working on a project to implement MKS Source Integrity, and it
appears that you can "drop a member" of a project with the *option* to
remove or retain the working file. History stays around forever (perhaps
unless you are an admin, but I haven't read that far). So, perhaps asking
the user if he would like to delete the working copy in the directory on the
hard drive (explicitness intended) would be prudent.
IMHO, the word 'release' should be reserved for the realm of release
management. i.e. svn may not ever use the term, but at least it would
conflict with the nomenclature of these who do employ the use some release
management scripts, procedures, etc.
Cheers!
-B
On 4/19/06, Duncan Murdoch <murdoch@stats.uwo.ca> wrote:
>
> On 4/19/2006 9:39 AM, Phil Endecott wrote:
> > Fabian Cenedese <Cenedese@indel.ch> wrote:
> >
> >> The problem in
> >> this case is that svn delete (without --force) didn't work in the first
> place
> >> as opposite action to svn add.
> >
> > I disagree, and I'll repeat my earlier suggestion, which no-one seems to
> have picked up on yet:
> >
> > "svn delete" shouldn't be trying to be the opposite of "svn add", it
> should by trying to be the same as a normal "rm" (or "del"), plus updating
> the Subversion data as necessary to record what it has done. "svn delete"
> should *always* delete the file in the working copy, and there should be no
> doubt in anyone's mind that it is going to do so since a "golden rule"
> should be that "svn XYZ" does the same as the OS XYZ command plus updating
> the Subversion data.
>
> This is how it behaves when the working copy is clean, without
> uncommitted changes. In the current situation with uncommitted changes
> it would result in loss of work, something svn tries really hard to avoid.
>
> I think the current behaviour is correct:
> "svn del" should behave as "rm" when the action is reversible, but
> should complain and require special flags when it would result in
> irreversible changes.
>
> Ryan Schmidt's suggestion to change the complaint sounds like the best
> solution to me:
>
> > "You cannot 'svn delete foo' because foo is not yet in the
> > repository. If you want to revert the scheduled addition of foo, use
> > 'svn revert foo'."
>
> > Reversing an add is not the same as deleting a file; it could perhaps be
> "svn subtract", "svn release", or something.
>
> Or "svn revert", as currently.
>
> Duncan Murdoch
>
> >
> > Thoughts?
> >
> > --Phil.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
-B
Received on Wed Apr 19 15:07:25 2006