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

David Roundy droundy at abridgegame.org
Mon Nov 22 12:27:48 UTC 2004

On Mon, Nov 22, 2004 at 02:51:46PM +1000, Anthony Towns wrote:
> Yup. I guess there are two key questions:
>   * What about previous history/patches to whatever version the user
>     wanted to patch?

I think previous history needn't be included in the manifest.  Darcs can
run many commands with a partial history, just like it can run with only
some of the patches (i.e. the result of get --partial).  When people start
using such a crippled repository, I'm sure they'll discover bugs that keep
them from doing commands that ought to be legal, but over time those
situations will become more and more rare.  And darcs *won't* do the
"wrong" thing when part of the history is missing.  Due to the wonders of a
lazy language, if darcs ever tries to access the missing portion of the
history, it will simply exit with an error.

The idea of introducing a "sibling" repository could be used to reintroduce
the old history, when a user wants to upgrade to a "full" darcs repository.

>   * What's the most pleasant format for getting this stuff to users?
> (Actually I thought there was a third, but I can't think of it now)
> Shipping a simple MANIFEST file seems fairly pleasant -- if you include 
> the generated files too and sign it, it works for authentication as well 
> as making it easy for users to turn themselves into developers; but otoh 
> shipping a skeletal _darcs/ tree means you could at least include a full 
> inventory which might come in handy.

Yeah, probably shipping a MANIFEST file would make more sense than some
kind of neutered _darcs/ directory.  In either case there would need to be
a darcs command to convert it into a "real" darcs directory.

> Oh, that's the third issue: keeping darcs as simple as possible internally.

Indeed, an important issue.  And when you've been around here long enough,
you'll realize that I very readily talk about adding new commands, but
actually add new commands pretty infrequently.  :)

> > 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.
> Hrm, I'd find "optimize" to be an odd command to be using; "init" or 
> "get" would make more sense to me if I'm somewhere I can't yet "record". 
> YMMV, IMHO, FWIW, blahblahblah.

Yeah, it's a hard call.  Optimize is sort of a catchall for changes that
modify your repository in a way that doesn't change its
meaning... uncompress, compress, checkpoint.  In a sense, that's what thais
change would do.  Get always creates a new repository (in a new directory)
so it's not quite what we want.  Init currently only creates an "empty"
repository, i.e. one with no history, so that's not quite right either.  :(

> >darcs optimize --from-hashed-tarball ../darcs-hive-0.5.tar.gz
> Does darcs really want to deal with variations like .tar.gz, .tar.bz2, 
> .zip, .srpm, .hqx? Hrm, I guess "darcs dist" already implies darcs has 
> to deal with tarballs in some sense, though.

Yeah, it depends on how closely we link this with darcs dist.  Probably
best *not* to link it too closely with darcs dist, in which case it's
probably a better idea to do something like

darcs init --from-manifest ./MANIFEST --sibling-directory \

where darcs will look in the -unmodified directory for unmodified copies of
the files in MANIFEST.  I'd rather not force the user to copy her changes
over from the modified directory with a cp -a...

> >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.
> You could call it "_darcs-skel" or something, to make it clear that you 
> need to use "darcs init --from-skel" before you can use record. Then you 
> can make "_darcs-skel" a Makefile target too. Maybe.

I'm now leaning towards the idea of treating this as a MANIFEST file,
rather than a _darcs directory.  I think this'll be easier to deal with,
and easier to explain.
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/20041122/4945b44b/attachment.pgp 

More information about the darcs-users mailing list