[darcs-users] RE: [Haskell-cafe] fptools in darcs now available

Simon Marlow simonmar at microsoft.com
Tue May 3 11:24:46 UTC 2005


On 01 May 2005 16:31, Daan Leijen wrote:

> Simon Marlow wrote:
> 
>> But what worries me is: if I just want to check out e.g. Haddock, I
>> have to get the entire fptools repo (350M+, wasn't it?).  I can
>> build a source distribution with just the bits I want, but I can't
>> get a darcs tree with anything but the whole lot.
>> 
>> So, here's two potential solutions:
>> 
>>  1. Make it possible to 'darcs get' just part of a tree.  Patches
>>     that don't touch any files in the "live" parts of the tree
>>     are discarded.  (I don't know if this is possible, or how    
>> difficult it is). 
>> 
>> 
> I like this solution, especially now that David says that it is not
> impossible to do. In general I think it is a good idea to be able
> to get a part of the tree -- this might be very useful to handle
> big projects like the linux kernel where many developers just need
> to touch tiny parts of the repository.
> 
> However, I think that darcs should never "discard" patches: all
> patches are always applied, and record works just as it normally
> works. The only difference is that the absent part of the tree is
> treated as an unobservable part of the tree -- patch applications to
> absent parts of the tree are just void operations as they can not be
> observed. In this design, a "darcs get" on a part of the tree is like
> building a special view on the tree.
> (As such, the tree should probably still always start from the root
> -- one would not be able to just get a bunch of leaves)
> 
> In this setup, I think darcs will still be able to transparently
> handle patches that touch present and absent parts of the tree, and
> also moves from absent to present parts etc.
> 
> In general, this feature might allow darcs to overcome most efficiency
> problems associated with large repositories. Alas, I do not know how
> much effort this feature might take (and I do not volunteer to do
> it), but it does seem a potentially important one.

If you don't discard any patches, then the size of the repository
probably won't drop very much, right?  Assuming the history is rather
larger than the size of the pristine tree, which is likely to be the
case in any long-lived project.

In any case, I'm now thinking that the other approach to splitting up
fptools is better: separate repositories for each project which
duplicate the shared parts of fptools, and pulling between these to
distribute patches to fptools.

Cheers,
	Simon




More information about the darcs-users mailing list