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

[Ketil Malde]

Peter Verswyvelen <bugfact at gmail.com> writes:

> I don't think it is realistic to expect that for a project of medium to
> large size that you work only with stable versions of modules (this would
> exclude most packages on Hackage I guess).

I think you're putting too much into "stable" here.  IMO, anything put
on Hackage is a release with its own, unique version number, and that
qualifies it for use.

You could conceivably have a patch-vs-patch granularity on the
dependencies, but I really don't want to go there - infinite
complexity with - as far as I can tell - no tangible benefit.

>> 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.

> Yep, that's the way it's usually done. But when you have multiple teams
> working on different modules within the same repository, this gets
> annoying.

If you have multiple teams working independently, they should work
with defined (and versioned) interfaces, produce separate packages, and
use cabal to deal with the dependencies.

If your teams need to poke around in each others code to work out
the dependencies, you really only have a one-team project where one
half of your team doesn't get to talk enough to the other half.

> Currently it mostly is a management issue, and so it often goes wrong :)

>> The developers should actually agree upon a proper set of API's before you
>> guys actually start building the modules separately.

> In an idealized world I agree, but with modern agile software development
> methodologies, these APIs also evolve...

..and get released, versioned, and made ready for import by the rest of
the world.

>>> To me, any version control system should be able to track
>>> dependencies between repositories. Something similar like Cabal's
>>> dependency system. 

Do one thing, and do it well.  File versioning and change history:
darcs.  Dependency tracking and building: cabal.  

(What if one of the teams decides to switch to a different VCS?)

>> Can you provide some examples of RCS that have such kind of
>> dependency system?

I'm more curious how and when it is necessary.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants