Re: [Monotone-devel] How to split a project

[Eric Anderson]

Hugo Cornelis writes:
 > On Tue, Feb 23, 2010 at 2:58 AM, Stephen Leake
 > <address@hidden> wrote:
 > > address@hidden writes:
 > >
 > >> [ Code that is used with multiple projects/ split/merge; hard to handle ]
 > >
 > > I don't understand the issue. What, exactly, do you mean by "include
 > > both these programs into another project"? In my experience, a
 > > "project" includes code from several different mtn branches. For
 > > example, at work I have the following mtn branches:
 > >
 > > [ list of projects with dependencies ]
 > >
 > > This means you have to run update, commit, and tag (for example)
 > > several times for each release.
 > 
 > [ with many projects, hard to do dependency tracking and have people
     step in and use it ]

 > [ script that does updates, syncs, compilation, testing, install, serve 
 >   monotone; looking for contributors ]

I can't offer to contribute, but I can say that we've built something
similar that we've been using for a few years called deptool.  You have
commands like:

 # create dbs, make monotone pubkey, etc, download branches starting with
 # ssd
 % deptool init --server=endpin.cs.hmc.edu ssd

 # checkout DataSeries and all it's dependencies
 % deptool co DataSeries

 # Build [and test] the current directory after doing dependencies
 % deptool build [-t]

 # Commit all the changes locally (after running tests)
 % deptool commit

 # Push the changes out for the current directory + dependencies to
 # the default mtn server after doing any merges that are necessary
 # and retesting if someone else updated the central repository
 % deptool publish

 # Review the changes made in one or more revisions
 % deptool code-review ab31515 13cdfeb

The two open source packages that we have that use it (with a simple
dependency between them) and instructions for building are available at:

http://tesla.hpl.hp.com/opensource/

The bootstrap version of the script (that includes some modules that
normally come with one of the packages) is at:

http://tesla.hpl.hp.com/opensource/deptool-bootstrap

We use it to make a much more complicated dependency graphs for some of
our internal development.  The top of the tree depends on 3 other
packages, and it builds some of them in multiple modes (option
automatically sent to cmake to control how the software is compiled)
The packages it depends on have further dependencies down the graph.

It may have some ideas that you could adopt.
        -Eric