[darcs-users] Small suggestion: lock/unlock and minor idiot-proofing

David Roundy droundy at abridgegame.org
Wed Nov 24 12:29:26 UTC 2004


On Tue, Nov 23, 2004 at 01:31:47AM -0500, James Bruce wrote:
> Sorry if this has been brought up before, as I'm a relative newcomer to 
> darcs (from your LKML announcement actually).  I have some possible 
> suggestions about the UI.
> 
> since "darcs unrecord" is dangerous for possibly public changes, how 
> about adding a "darcs lock" command that makes a lockfile, so that you 
> can't pull from that repository (or maybe requiring --force to be 
> specified).  Then you don't need to worry about record/unrecord/rerecord 
> while it is locked.  When you are done, just "darcs unlock" and people 
> can start pulling from you.  It also should not allow "darcs push" so 
> newbies like me don't accidentally share something.  This seems quite 
> easy to implement by simply creating a _darcs/lock file, and having 
> pulls etc check for that file first.

It definitely *can't* be called _darcs/lock, since that lock file is
already used and is a write lock... :)

But I like the idea.  Most of what other people have said is true, but the
your scheme adds the ability to block pulls, which is most certainly a good
thing to support.  I don't think we can do this with absolute safety, since
someone may already be pulling when we lock the repository, and we may
unlock it by the time they finish pulling.  One way around this would be to
have a sequential lock, storing an integer in the file, odd meaning locked
and even meaning unlocked, and we increment it when locking or unlocking.
Then a pull could check that both before and after the files are downloaded
the lock has the same value (assuming there's no caching proxy in between
that might be ignoring our cache time).

So to summarize my former long-windedness, aside from the fact that you
shouldn't unrecord patches that have previously been pulled (which can
cause merge conflicts, but not corruption), if someone is pulling (or
getting) *while* you unrecord a patch, they could end up with a corrupt
repository, which would be very bad.  So a read lock would be useful even
without a lock command that would set it manually.

I also think that setting the lock manually could be useful.  To make
things really, really safe, we'd also need to keep track of patches that
were recorded while under a given lock, and then require that only those
patches can be unrecorded or amended.  This would be a bit more work, but
might be worthwhile.  Once we had a mechanism for dealing with this, we
could have some sort of a --private-only flag to unrecord etc (which could
be made the default) which would only allow them in locked repositories.

As I hinted above, though, the way to start this is in a
user-interface-free manner, by adding a read lock that is automatically
taken when necesary.

Note that (contrary to the fears of someone in this thread) there is
(unless there are unknown bugs, of course) no danger from applying or
recording while someone pulls.  Or from pulling in another direction.
Under these commands, darcs doesn't update the inventory of patches until
the patches themselves have been written, and doesn't modify the contents
of any of the existing patches, so any already-running get or pull will run
just fine.  It's only the "unsafe" commands that are "unsafe" when run
concurrently.

> Also there's this rule:
> > Rule number one of working with darcs: never do anything interesting
> > when "darcs what" doesn't say ``no changes''.
>
> Why not just have those commands say "you have local changes, commit 
> them, or if you really know what you are doing, rerun with --force". 
> Around my lab we end up teaching undergrads how to use SCMs since they 
> rarely seem to learn about them in classes.  Making a bit harder to 
> shoot yourself in the foot is in general a good thing.

This rule is a bit of an overstatement on the side of conservatism.  The
key word is "interesting", which I would interperet to mean "something that
you aren't quite sure what it will do."  Except of course, it isn't about
your certainty, but rather about whether you're right.

If you follow this rule, you can't lose data (except if you use unpull or
revert), which is good.  But on the other hand, I certainly don't use darcs
that way, and you shouldn't *need* to use darcs that way.

I'd rather make darcs recognize with more accuracy potentially dangerous
situations, rather than generically insist (or strongly suggest) a
hyper-conservative work pattern.  For example, we (I think it was me,
actually, at someone else's suggestion) recently added a warning message
with option to cancel when you pull a patch that conflicts with unrecorded
local changes.  This means you are only bothered when there actually is a
conflict, which hopefully is rare.

Of course, darcs has enough weird commands (alas) that it'll take time to
plug all the holes that let people shoot themselves in the foot, but I'd
rather do it right.  Unnecesary warning messages can be as bad as errors to
inexperienced users.  I know the warning that shows up when a command will
prevent a future "unrevert" has confused users who didn't understand it.
Making the message clearer should help, but giving fewer warning messages
in general I think is the best plan.
-- 
David Roundy
http://www.darcs.net




More information about the darcs-users mailing list