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

Re: The common options

From: Branko Čibej <brane_at_xbc.nu>
Date: 2000-10-23 04:08:46 CEST

Karl Fogel wrote:
> Regarding these two:
>
> -r --read-only Make new working files read-only.
> -w --writable Make new working files read-write.
>
> Does anyone here actually use them?

Me!

> I've never had occasion or desire
> to check out working copies anything but read/write... But maybe this
> is important?
>
> If it turns out that none of us do it, I think it may not be worth
> supporting this.

I'd like to throw a small spanner in the works and suggest that
we need to support reserved checkouts and persistent locks on
the repo (the same thing, really), and --read-only should be the
default in such cases. Without going into details right now, I'll
just state a few reasons:

    - Users want them. A lot of people around me are using CVS
      (it beats the hell out of RCS), but would prefer to have
      reserved checkouts instead of having to merge changes and
      -- as has happened -- commit files full of conflict markers
      by mistake.

    - 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.

    - Release management. Lock the release branch and only let the
      release manager check in changes.

    - Usage tracking. Who's editing what? Just list the locks.

Most of that can probably be accomplished by modifying access rights,
but having persistent locks would be a good thing, IMO.

(Now, since asbesthos suits are politically unacceptable lately,
I'll have to see what's new in the ceramic heat shield business.)

-- 
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.