[darcs-users] Colin Walters blogs on Arch changesets vs Darcs

David Roundy droundy at abridgegame.org
Sun Nov 21 12:35:13 UTC 2004

On Sun, Nov 21, 2004 at 06:23:53PM +1000, Anthony Towns wrote:
> That seems pretty easy. You need two programs -- one that takes a 
> repository that has a TAG associated with it and generates some manifest 
> file, and another that takes that file and a tarball directory and 
> creates a compatible (partial) _darcs/ tree.
> Because users suck, you need to do some authentication too, so we want 
> the manifest file to look like:
>   aj at azure.humbug.org.au**20041121035651]
>   **
>   adf2acdc15c84a905189346934ecca1b 490 ./BUGS
>   284ede192494b511a58bfeabd71e4c0f 589 ./darcs-scp
>   80c439f2fc9119c6f5165da872da73de 473 ./darcs-ssh
>   dd145a47eebf7c23e5c00e739e4cfc71 6622 ./darcshive
>   854585c02722ee0b639b363acdf3be3b 409 ./darcshive.cgi
>   1692159f74ff844afe729c6097c7dcd7 1724 ./README
> so if BUGS isn't 490 bytes, or README's md5sum has changed we won't 
> accidentally create an incompatible repository.

Hmmmm.  This is interesting, in that it sounds a lot like one of Juliusz's
ideas for spiffing up Current, which is to store hashes of all the files in
_darcs/current, rather than the files themselves.  His idea was that we
could then generate from patches the actual file contents, when needed
(which could be more than a tad expensive).

However, the idea has interesting promise for a (perhaps?) nice treatment
of creating darcs patches from tarballs.  What if the tarball itself is a
"partial" darcs repository with hashed current?  Basically, this would be
equivalent to having the manifest you mention, but it would be stored in a
few files in _darcs/.  We'd then need to add a command to switch between
hashed current and non-hashed, which would check the files in the working
directory, and if they match the hash it would just copy them into
_dacs/current/, and if they don't would try to create them from the patches
(which would fail in the tarball), and if it fails at that, would complain
that the user modified the files.  I'm imagining the command being a flag
to optimize:  darcs optimize --from-hashed-current, or somesuch.  It could
accept a tarball optionally as an argument, to get the "clean" sources.

So the procedure for a random joe user to contribute a patch would be:

tar zxvf darcs-hive-0.5.tar.gz
cd darcs-hive-0.5
...hack, hack, hack...
# (oops, now I realize I want to contribute back...)
darcs optimize --from-hashed-tarball ../darcs-hive-0.5.tar.gz
darcs record -m 'cool contribution'
darcs send

The question would be how to generate the tarball in the first place.  If
you use darcs dist, this is pretty easy.  But alas, there are good reasons
for using automake, for example, and I'm not sure how we could make it
really straightforward to convince automake to generate the appropriate
_darcs.  When using automake, it would probably more convenient to call the
file MANIFEST or something and just make it a target of the makefile.

I guess now that I think about it, perhaps MANIFEST *is* the way to go.
One could create a darcs command (or your shell script) called "manifest",
which dumps a listing of files and hashes and the current context.

(in makefile)
MANIFEST: _darcs/inventory
          darcs manifest > MANIFEST

Then add a --from-manifest flag for get should allow

darcs get --from-manifest ../darcs-hive-0.5.tar.gz

where --from-manifest tells darcs to look inside the tarball to find a
file called MANIFEST, and then use that file along with the contents of the
tarball to make the current directory a darcs repository... or to create a
new darcs repository? Or should this be a flag to init?

I think I'm going in circles (I almost caught my tail!), so I'll stop now.
David Roundy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041121/7b4a8895/attachment.pgp 

More information about the darcs-users mailing list