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

Re: Reserved checkouts

From: Branko Èibej <brane_at_xbc.nu>
Date: 2000-10-24 03:24:24 CEST

Jim Blandy wrote:
>
> I'm going to totally avoid the question of reserved checkouts, and
> just comment on one proposed use of them:
>
> Branko =?iso-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
>
> > - Repository backups. Lock the whole repo, do the backup, unlock
> > it. A backup of a repository for a large project can take a *long*
> > time. You don't want people to check in changes during that time,
> > but there's no reason to forbid checkouts.
>
> Why don't you want people to check in changes while you back things up?
>
> If you're worried about the repository being in an inconsistent state,
> don't be. Berkeley DB provides easy ways to make this work.

That's great, one less thing to worry about.

I'm beginning to think it should be possible to get most of the
effects of reserved chekouts with appropriate access privileges,
and maybe a "cvs edit" equivalent combined with a bit of
server-side scripting.

I still think, however, that we need to at least provide the
hooks to make it possible.

(But not like "cvs admin -l", which is a poor substitute. Whether
checkouts should be reserved or not is part of project policy, and
therefore a property of the repository/object/branch/whatnot.)

I know I'm pushing things a bit here, but from what I see people
are often uneasy about unreserved checkouts. Having support for them
would make SVN acceptable to more people. In fact, they're on the
wish list of many people that use CVS in the company where I work,
and would be a major argument for them in favour of switching to SVN.

-- 
Brane �ibej
  home:   <brane_at_xbc.nu>            http://www.xbc.nu/brane/
   ACM:   <brane_at_acm.org>           http://www.acm.org/
Received on Sat Oct 21 14:36:12 2006

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.