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

[Xiao-Yong Jin]

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.  Usually, if your
project depends on other projects, mostly it should work
with stable version of other projects, but not their develop
version.  You might need some features of other projects
that is still under development, than you might have a few
repositories.  However, such situation should be well known
across all developers of your project.  And usually you guys
should agree on one particular develop version of those
dependency projects, to make sure that you guys are working
with the same set of API's.

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.  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.  But we are using a distributed
revision control system, as darcs is, you can choose which
patch to push to the "upper stream" anyway.

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.

Another reason for such kind of RCS built-in dependency
check being impossible is that darcs are basically dealing
with a bunch of dependent patches.  Those patches only know
their dependencies within a particular repository.  You
can't logically put a dependency of an external repository
before you start pulling from that repository.

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

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

>
> So my question is really, how do you solve the dependency
>tracking between
> several Darcs repositories? 

Because every source tree is a branch in darcs, you can't.
-- 
    c/*    __o/*
    <\     * (__
    */\      <