All but the first case you list below sound like they'd be provided by
a good permissioning system or a separate event-tracking/accounting
system, not by reserved checkouts.
I don't think locked checkouts are always a bad thing, but also don't
think they should be a high priority. If anyone sees a way in which
Subversion's design limits their possible future implementation,
please raise a red flag. But otherwise, I think it's one for the TODO
Even in the first case you list below, the only one in which reserved
checkouts are actually necessary, no huge harm has been done: someone
resolves the conflicts and commits. Or, the project has a hook script
which prevents files from being committed with conflict markers.
Branko =?iso-8859-2?Q?=C8ibej?= <firstname.lastname@example.org> writes:
> 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