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

Re: Does locking feature imply need for 'svn release'?

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-02-09 08:32:11 CET

On Tue, 8 Feb 2005, Ben Collins-Sussman wrote:

>
> On Feb 8, 2005, at 4:00 PM, kfogel@collab.net wrote:
>
> > I'm forwarding this exchange from the users@ list:
> >
> > Greg Thomas <thomasgd@omc.bt.co.uk> writes:
> >> On Tue, 8 Feb 2005 11:08:21 -0000, "Max Bowsher" <maxb@ukf.net> wrote:
> >>> Patrick Gelin wrote:
> >>>> When I finish with a local copy of work, how to release it
> >>>> properly. With
> >>>> CVS it's: cvs release -d path
> >>>
> >>> Just delete it.
> >>
> >> What happens if I'm using 1.2, and I've locked a file in my working
> >> copy? OK, so others can --force the lock, but I wonder if there's a
> >> need for a 'release' equivalent that would release any locks in the
> >> wc.
> >
> > I'm assuming that 'svn unlock' from the top of the working copy would
> > take care of this. But, checking here with the locking implementors
> > to make sure that is indeed the intention...
> >
>
> 'svn unlock' isn't recursive, but I suppose we could add an optional
> --recursive flag to it?
We could do that, but then comes the next question: why doesn't svn lock
have --recursive? Well, we could add that too, but it would be a lot of
work (for the client and server, not for implementing), so I'm not sure we
want this. Also, we want directory locking in the future, maybe.

Another question is if it really will help in the situation mentioned
above. Won't people normally just get rid of their WC and forget about any
locks.

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 9 08:34:04 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.