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

[Peter Verswyvelen]

On Sun, Mar 29, 2009 at 10:26 PM, Xiao-Yong Jin <xj2106 at columbia.edu> wrote:

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


Even if you have just two modules, manually keeping track which version used
which other version feels error prone. And you need that when you want to
revert to old versions (which I heard is very hard to do with Darcs anyway,
but I can't confirm that, haven't tried it yet)

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 understand this is the way it
*should* be, but I don't think it often does. I prefer to use some unstable
packages from Hackage, and contribute bugfixes or even enhancements to these
packages.


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


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


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


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


Sure, but that sounds like a current limitation, doesn't seem like this is
impossible to extend.

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

Mercurial had an
extension<http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension>for
this. I'm not sure but maybe ClearCase and Accurev also support
something like. A couple of years ago I also developed a version control
system (closed source, private solution for customer, NTFS only) that
supported dependencies between repositories ( too bad that company did not
want to release the software as open source :|  )

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


Too bad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090330/fa699e37/attachment.htm