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

Re: 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 15:26:16 CEST

On Fri, Sep 23, 2005 at 02:59:53PM +0200, nick vajberg wrote:
> > 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?
> Perhaps not? I don't know SVN's internals much, but
> how about this:

I was speaking about the semantics of the operation, not the physical
implementation (perhaps I should have said 'network' rather than
'RA layers').

Perhaps I should just try to rephrase what I meant:

As I understand it, you're proposing a new logical operation (like 'add',
'move', 'delete'), called 'unversion', that would need to be recorded
in the repository and communicated to all clients. The 'unversion'
operation is essentially 'delete entry from repository but not from
working copies'.

Quite apart from any implementation difficulties, I have an objection to
the concept of this operation, as defined, in that it would be possible
for any client to 'break' another client's working copy, requiring manual
intervention to fix, using a combination of 'unversion' and 'add'.

I contend that this violates a core promise of Subversion - and other
linear centralised version control systems - that it should not be
possible to enter a conflicted state by simply moving a pristine working
copy forward or backward in time.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 15:27:00 2005

This is an archived mail posted to the Subversion Dev mailing list.