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

Re: Re: Feature request:: Unversioning files (svn rm --keep-in-wc)

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2005-09-23 13:30:29 CEST

On Fri, Sep 23, 2005 at 01:02:26PM +0200, nick vajberg wrote:
> > What would happen to other users' project files when
> > updating the
> > --keep-in-wc removed file?
> It would be unversioned, of course.

So, in other words, this is effectively a new operation, something like
'delete-but-don't-delete-working-copy', that must be communicated across
the RA layers and stored in the repository?

If so, I have an immediate objection. Apart from the obvious problems
(compatibility, implementation) it would allow any user to place all
other users of the repository into a conflicted state:

[Assume the pre-existence of a file called 'foo']
$ svn rm --keep-in-wc foo
$ svn ci -m log_msg

$ svn add foo
$ svn ci -m log_msg

Now, any user doing an 'svn up' will hit a conflict, because the
unversioned file left behind by the first revision will obstruct the
add operation in the second revision.

I'm strongly of the belief that with no local modifications, 'svn up'
should always succeed. I'm fairly sure that some applications depend
upon this behaviour (automatically updating websites, for example).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 13:31:28 2005

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.