[darcs-users] Using Darcs for Debian package maintenance

[Max Battcher]

Christoph Haas wrote:
> - I cannot easily check in my changes into a central repository through
>   an HTTP proxy. The concept of distributed repositories is indeed a bit
>   new to me. But using (procmail) scripts that automatically import
>   GPG-signed patches sent through mail sounds more like a workaround
>   than a good solution. Subversion uses WebDAV which is pretty
>   compatible even through proxies. I know a developer who manages his
>   Darcs repository locally making it publicly visible as a web site (as
>   described on darcs.net) and just accept patches from other people in a
>   cherry-picking manner. This might be okay for first- and second-class
>   maintainers. Of course every participant in a project can run a web
>   server to show their current state. But equitable maintainership
>   sounds harder this way.

Darcs is _very_ protocol agnostic.  As long as you 1) copy patch files 
to the remote machine and 2) call the remote machine's ``darcs apply``, 
you can submit patches.

The easiest way is just to set up SSH accounts for the users that wish 
to submit patches, and Darcs is more than happy to use SSH to push/pull 
patches around.

Most Darcs HTTP setups are for the read-only public access to 
repositories, and they are just like any other web-accessible directory. 
  All Darcs does is file downloads, and most Proxies don't have a 
problem with that.

> - I read rumors that Darcs isn't yet stable enough for serious use (e.g.
>   hanging in loops that take hours). While I don't mind using something
>   non-stable to report problems and help improve the software I wonder
>   how "beta" Darcs really is.

Basically its a scale issue.  I personally have never encountered any of 
these long operations, but I don't use very large repositories either.

These performance issues are continually being adjusted and made better. 
  Each version continues to improve I/O performance, and a branch of 
Darcs development (Conflictors) is working hard to increase Merge 
conflict performance.

> - Darcs does not know about file permissions. If I store executable
>   files (e.g. shell scripts) then other people who check those out first
>   need to fix the permissions manually. Is this a feature?

Basically it is a feature.  Darcs attempts to be platform agnostic and 
there is no good way of storing permission information cross-platform.

One of the typical solutions is just to include a permission setting 
shell script in your repository and let people chmod 755 your.script && 
./your.script, which gives you full control of permissions.

I'm largely a Windows guy, so it doesn't mean as much to me to have 
permissions control as few applications get them right to begin with. 
That should change soon, though.

> - Some operations seem to mean changing files in the _darcs subdirectory
>   manually. Like the "boring" files for example. This sounds like it's
>   not only done in very rare cases where I have to override Darcs'
>   default behavior but rather on a common basis. I had expected to just
>   use the proper darcs command-line tools to maintain the repository.
>   In other RCSs I don't care about the internal structure of the
>   repository either.

All of these files are under _darcs/prefs, which is the repository-local 
configuration directory, so they are meant as configuration files just 
like you'd have in any other environment.  Just because it is under 
_darcs doesn't mean you have to worry about accidentally destroying 
something.

> - I missed something like "svn stat" to see which files in the current
>   directory are under repository control. The kind people in #darcs
>   (IRC) recommended "darcs whatsnew -l" which is similar but shows
>   everything recursively which can become a lot of output. Or as an
>   alternative I was recommended to just look at _darcs/current. But I
>   wouldn't want to compare my current directory to what's in
>   _darcs/current actually.

In more recent versions of Darcs there is ``darcs query manifest``.

> - As I'm not familiar with branching I can't really tell whether
>   branching in Darcs is handled badly (I read a branch is a full copy of
>   the repository's directory tree in the file system). But many people
>   love branches because they try things out in other branches and then
>   merge it back in. Do you use them often?

Darcs makes branches stupidly simple and there is almost no reason not 
to use them (a lot).  The "every copy of the repository is a branch" 
removes the mental overhead involved in other SCS' branching.

Suppose that I want to work on a feature that may take some time I can 
just ``darcs get /my/main/repository`` into a new directory and work on 
that feature there.  Then its just the simple job of pushing back my 
changes once I finally finish them.

Darcs even knows to hardlink the patches in the local system ``darcs 
get`` operation (on systems that support that) so you aren't incurring 
as much overhead as it sounds.

-- 
--Max Battcher--
http://www.worldmaker.net/
"I'm gonna win, trust in me / I have come to save this world / and in 
the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track)