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

[Daan Leijen]

Simon Marlow wrote:

>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.
>  
>
No, I don't think this will be the case -- it is possible to optimize
darcs to not pull patches that are not relevant to your view on the tree.
We can even checkpoint views. As David said, once darcs maintains an index
of which patches influence particular files/directories it is easy to 
optimize
this. Maybe views should be defined explicitly to help darcs do this.

Of course, I do not know how hard this will all be. However, it has the
advantage of having a clear semantics model where certain operations can 
just
be optimized. If we make it more operational -- where certain patches are
discarded -- I am worried that certain operations will unexpectedly fail
(for example, inter-view file moves).

However, this is just my opinion and I am not an expert of darcs internals
-- maybe others can give a more informed view on this :-)  I still feel
though that one unified repository is the right way to do it, where darcs
can potentially optimize certain views on the repo. I agree though that
for practical reasons, one might choose otherwise.


>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.
>  
>
I think you mean that you would put each project (sub-directory) in a
separate repo. The advantage would be that it works well with current
darcs and is simple. Potential drawbacks:
- it is hard to get the "latest" fptools
- it is hard to update everything
- it is hard to migrate code from one project to the other (or 
reorganize the tree)

Is this correct?
-- Daan Leijen.


>Cheers,
>	Simon
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-users/attachments/20050503/27ef8738/attachment.htm