[darcs-users] locking

Jason Dagit dagit at eecs.oregonstate.edu
Wed Feb 22 16:37:34 UTC 2006


On Feb 22, 2006, at 5:28 AM, Matthias Fischmann wrote:

>
>
> hi,
>
> I am trying to figure out a locking procedure for a repo containing
> mostly 5 tex files and shared by 5 people.  I couldn't find any
> equivalent to 'svn lock', but relying on auto-conflict-resolution also
> seems a bad idea if the repository constists mainly of three to five
> latex files.

We used darcs for a paper recently with three authors.  Reflecting on  
our experience, I would say in the ideal case I'd have a wiki which  
supported latex instead of wiki markup and generated HTML by default  
but also generated pdf files for download.  The general impression  
that I got from using darcs (or any version control for authoring  
latex documents) is that it is very inefficient given the specialized  
domain of publishing.  If I were forced to author more papers I would  
create a plugin for mediawiki for this type of authoring but  
fortunately I'm not often faced with this need.

When you're editing source code you may very well want a local copy  
of the code that diverges from the "official" version.  Darcs really  
enables this with its distributed nature.  Conflicts between versions  
is not detected until it is absolutely necessary that you deal with  
it.  For things like open source development this is a win, plus it  
lets me work on a feature for a couple weeks before integrating my  
code with the work of others.  It helps you have different releases  
of the same source code as well.  When I've been an author on a paper  
we needed to centralize things and fight the divergence as much as  
possible.  The way darcs works was fine for individual sections of  
the paper that belonged to a specific author but the common sections  
like the introduction were hard to share using darcs.

>
> My idea was this: (1) If somebody starts working on a file, he
> broadcasts an e-mail to the project that this file is locked.
> Everybody complies.  When the work is done, a 'free' message is
> broadcast, again via an e-mail read by all project members by hand.
> (2) If another person wants to work on a locked file, she can call the
> lock owner and neegotiate, probably resulting in (3) the file being
> split in two files and a fresh pair of locks being broadcast over
> e-mail, replacing the old one.

You could use posthooks to automatically broadcast messages when  
changes are applied to a central copy of the repo.  I was going to  
suggest using tags as a form of lock but on second thought that's a  
bad idea.  If you were really interested in exploiting current  
features of darcs you could use the 'test' with a script that checks  
for a lock file to see which files are locked and which user name  
wants to edit a given file and complains when a file is locked by a  
different user.  You could do additional things such as setting a  
posthook to email everyone when a lock is added or removed from the  
lock file thus automating the broadcasts.  It's possible that two  
people could edit the lock file and not get a conflict so probably  
what you'd want to do is list every file in the repository in the  
lock file and then on the same line as the file name specify if the  
file is locked or not.  That way, whenever two people try to lock the  
same file a conflict will be generated.  Of course this assumes your  
users will 1) edit the lock file, 2) record and push a patch  
containing just that editing of the lock file 3) work for a bit 4)  
record changes in several patches and record unlocking in a separate  
patch 5) push all patches.

>
> This will probably do for this particular type of repo, but I was
> wondering whether anybody here has come up with better / other
> solutions?

Well, the process I just described might give you a way to partially  
automate what you described.  But as I think about it more I realize  
that what I describe could be a total pain.  Your authors now have  
this special patch they have to send in that is used to synchronize  
each other.  This isn't bad per se, but it requires that people will  
update their local copies whenever there are changes which means  
you'll need/want to automatically send out notices when the repo  
changes.  I think this directly relates to the problem we had where  
the darcs model was inefficient for paper writing and a wiki would be  
much better.

It would be interesting to compare notes when you're done with the  
authoring of this paper and let us know how it goes and how you solve  
your problem.

Thanks,
Jason





More information about the darcs-users mailing list