[darcs-users] Centralized Darcs usage

[Jason Dagit]

On 4/20/06, Sébastien Pierre <sebastien at xprima.com> wrote:
> Hi all,
>
> I am currently evaluating different VCS for usage in a centralized
> organisation (see below). As a Darcs user, I have been very pleased
> so far, but found myself unable to answer the following questions :
>
> 1) Is it possible to know if a particular file is being "worked on"
> by somebody else ? For instance, I would like to know if the file
> "module/main.py" is currently being modified by somebody. My guess is
> that this is not really possible with a distributed VCS like Mercurial.

This would not be possible with darcs alone.  You'd need some other
mechanism to communicate this.  If I recall correctly,  you could
simulate this (a tiny bit) with pre-hooks but darcs only has
post-hooks at the moment.

> 2) Is it possible to work only on a subset of a repository ? For
> instance, if I have a large project (hundreds of subdirs, large
> tree), can I "cherry-pick" a particular subdirectory, make it my
> working directory and then push my changes back to the "main"
> repository ?

You could nest the repositories but I would recommend against it.  I
think in your case everyone on the team will end up checking out a
full copy of everything, modifying his or her part and then checking
that piece in again.  Other than that, you could manually fator things
out in to seperate libraries and such.

>
> To put this into context, the centralize organisation I mentioned is
> as follows:
> - 1 "main" repository, that is used by all devs as a reference (this
> is where the things that will go on production are)
> - N devs who work on projects thats are subdirectories of this main
> "directory"
> - Each dev has its own local repository in its ~/home
> - Each dev commits to the "main" repo when changes are assumed to be OK

The way people seem to do this in practice is that everyone has their
local repository (or think of it as a branch if you prefer) and there
is a central repository for aggregating and merging everyone's
branches.  Let's call this the foo-unstable repository of the foo
project.  As changes are deemed safe for production they are cherry
picked to to the foo-stable repository.  The cherry picking of darcs
even allows you to bypass foo-unstable when necessary.

Further you can argue that changes are going through three filters. 
1) the developers personal filter of what they deem worthy, 2) the
requirements of the unstable branch and finally someone like QA can
approve patches in ustable for migration to stable.

I'll pick on subversion the example of a good centeralize version
control system.
I think in your case it really boils down to what you want to give up.
 To use darcs you have to give up file claiming and subrepository
checkouts, as compared with subversion.  What you gain over subversion
is cherry-picking, the rather nice interactive interface of darcs, and
automatic branching.

Depending on your organization there is also the problem of
'mainstream' tools.  That's the problem where I work currently.  As an
organization we tend to give preference to mainstream tools for
various reasons that I won't go in to here.  But I do use darcs
whenever I can because I like it better :)  Now if I could convince
them that Haskell would save me development time and hence save the
company money :)

Good luck, and it will be interesting to observe the technical and
non-technical factors that shape the decision your team makes.  It may
turn out that you gain insight that would help improve darcs.

I think this website could help you a lot in your evaluation:
http://better-scm.berlios.de/comparison/comparison.html

Jason