[darcs-users] dvcs article
Trent W. Buck
trentbuck at gmail.com
Sun Feb 1 05:42:00 UTC 2009
Isaac Dupree <ml at isaac.cedarswampstudios.org> writes:
> Max Battcher wrote:
>> The only remaining argument is space efficiency ... and if you are
>> worried about working tree space on a desktop/laptop then you probably
>> have other problems to worry about...
> GHC working tree is 100s of megabytes. I make a few branches to hack on a few
> features, it gets into the gigabytes.
That should not be the case, because hard linking will happen
automatically between repositories (as long as they are on the same
filesystem). Of course, that assumes that you're using Darcs 2 with a
repository in darcs-2 format -- something I believe the GHC project does
> Then it comes time to do backups, and my backup space *is* rather
As for backups, you can preserve the hard links (thereby preserving the
space savings) by using the appropriate flags for your backup software.
> (best current options are a shared backup disk,
For example, rsnapshot requires you call rsync with -H; and
> and DVD-Rs).
I guess mkisofs needs -cache-inodes.
> [...] ways in which we drive away people who like using low-powered
I think that only applies to developers with atypically large (for FOSS,
anyway) codebases. I've no problems with disk space storing a dozen or
so branches of Darcs (and similarly-sized projects) on my Eee PC's four
> I think it's worth some energy to mitigate. (although
> there's nothing obvious for darcs to do other than continuing becoming
> a well-optimized RCS in patch-interface and code)
The obvious solution to your problem (other than to suck it up and use
git-svn on subtree checkouts) is to allow multiple branches inside a
Darcs repository. The downside is the extra confusion from having
multiple branches (and a single working tree that may not match ANY
branch) and a bunch of extra subcommands that are only useful when
working with multiple branches in a single repo.
> I think though, these repos of mine could be archived with context-files and
> darcs-send stuff (and hopefully then be able to reproduce it from the current
> versions of public repos)... if only there was something in the darcs manual
> explaining how to think that way.
That would be "darcs send -aO ../parent-branch", I guess, and then move
the resulting file into an empty directory ../archived-branches.
More information about the darcs-users