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
list.
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.
-K
Branko =?iso-8859-2?Q?=C8ibej?= <brane@xbc.nu> 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