[Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)

[Thomas Davie]

On 29 Mar 2009, at 22:26, Xiao-Yong Jin wrote:

> Peter Verswyvelen <bugfact at gmail.com> writes:
>
>> Mmm, my email was indeed very unclear about my question.
>>
>> A very simple example: suppose a development team is working on a  
>> program.
>> This program consist of modules A and B. Each module has it's own  
>> Darcs
>> repository.
>>
>> Module A requires B. When a new developer wants to get the source  
>> code, he
>> does a "darcs get server://program/A", which gives him only the  
>> latest version
>> of A. So he manually needs to do "darcs get server://program/ 
>> B" (that B is
>> required is usually discovered after a compilation error, talking  
>> to other
>> developers to find out what the dependencies are, or by reading the  
>> cabal
>> file). Furthermore it is unclear which version of A required which  
>> version of
>> B (so you can't really roll back to old versions).
>>
>> Now assume you don't have 2 modules but dozens...
>
> I can't imagine such kind of situation, unless you are
> really working on a very big project.

Really?  To me it's almost the way darcs is *meant* to work.  Both  
darcs and cabal work well when you work with micropackages, not one  
monolithic thing.  What Peter is suggesting would make darcs hugely  
better for dealing with lots of micropackages at the same time that  
all go together to form a project.

> If those aforementioned dependency projects are just some
> modules within your big projects, I think the way to go is
> actually make them in the same repository.

Really?  Why should we make a monolithic blob out of what are really  
completely separate things that can be reused in completely separate  
places?

> I can't see the
> benefit of splitting those small modules to different
> repositories, apart from not letting other people know your
> current developing code.

As above – they're different packages, that do something different,  
and can be used in many different places.  It's pure coincidence that  
those packages were first needed for this particular project.

> So my point of view is that it is a management issue rather
> than a issue of revision control system.  The developers
> should actually agree upon a proper set of API's before you
> guys actually start building the modules separately.

I don't agree.  If it were stable APIs developed by someone else, then  
yes, it would make sense, but with packages that are built side-by- 
side with the rest of the project, but are logically distinct, it  
makes very little sense.

Bob