On Wed, Feb 22, 2006 at 08:37:34AM -0800, Jason Dagit wrote: > To: Matthias Fischmann <[EMAIL PROTECTED]> > Cc: [email protected] > From: Jason Dagit <[EMAIL PROTECTED]> > Date: Wed, 22 Feb 2006 08:37:34 -0800 > Subject: Re: [darcs-users] locking > > > 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. > > [...] > > 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.
Hm, i don't see why this couldn't be done in cvs with a well-designed tagging policy. Every author gets a private name space for tags like AUTHOR_* and can branch off any state of the repository to fool around without bothering anybody else. Plus, he can very easily tell others to have a look at it by simply posting a tag that all others can use. I haven't used tags in darcs yet, I am still under the impression that they are strictly more powerful than that. Anybody here to contradict me? (: Sidenote on wikis: The problem with all wikis I know (and especially mediawiki) is that it is based on a very poor user interface and has a very poor markup language. Also it is ultimatively restrictive with document types (clumsy at handling images, impossible to handle anything more exotic) and hard to script. Apart from that, I really liked it when I had to work with it. Might do it again once it's based on a decent version control system and a shell / emacs interface. > >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. Very inspiring, thanks. I now believe that a convenient locking can be implemented relatively easily on top of darcs. Also, the previous discussion has made me hesitate to do it. I think I'll have to go play with tagging, manual conflict resolution, and non-standard diffs. (How do you plug the latter into darcs?) I'll keep you posted. Thanks for the input. m.
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
