monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hugo Cornelis
Subject: Re: [Monotone-devel] How to split a project
Date: Tue, 23 Feb 2010 06:11:31 -0600

On Tue, Feb 23, 2010 at 2:58 AM, Stephen Leake
<address@hidden> wrote:
> address@hidden writes:
>
>> Let's say I have some code checked in along some branch.  Over the year
>> it has evolved so that it has become two separate programs, that don't
>> share any code any more, and make sense to develop independently.
>>
>> Evidently, it makes sense to make two branches, one for each program.
>> The obvious way is just start new branch(es) and in each branch delete
>> all the files now belonging to the other.
>>
>> BUT.  If years down the line, someone wants to include both these
>> programs into another project, I don't want the merge saying, let's
>> merge all these changes.  Looky here, all the files of each branch have
>> been deleted on the other.  There's nothing left!  And that someone
>> mysteriously end up with no files instaed of all the files.
>
> 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:
>
> makerules
>    shared sets of common Gnu make stuff
>
> sal
>    Stephe's Ada library - basic math stuff
>
> opentoken
>    parser generator
>
> common
>    mission-independent Goddard Dynamic Simulator stuff
>
> gpm
>    Global Precipitation Measurement mission
>
> mms
>    Magnetosphere Multi-Scale mission
>
> sdo
>    Solar Dynamic Observatory mission
>
> gpm, mms, sdo are the top-level projects; the others are essentially
> libraries.
>
> mtn doesn't know about this structure; only the makefiles do.
>
> This means you have to run update, commit, and tag (for example)
> several times for each release.
>

Yes.  If one has many software projects to maintain, it quickly
becomes a load of work.  It also makes it difficult for new people to
step into software development, for example, because dependency
tracking between software components must be done manually.  For a
couple of years we have been working on a script that automates the
management of multiple monotone projects.  We are currently looking
for people who would like to contribute to this system.

The system automates updates of local source code, synchronization
between distributed repositories, compilation, testing and
installation, packaging and releases, serving monotone repositories
and other things.  Besides monotone it also has experimental support
for integration with mercurial.

An overview of the software components that we maintain with this
system can be found here:

http://www.genesis-sim.org/userdocs/developer-repository/developer-repository.html

The supported developer work-flows are discussed in

http://www.genesis-sim.org/userdocs/workflow-developer/workflow-developer.html

A discussion with technical details of this system (such as separation
between software components and the operations run on them) can be
found here:

http://www.genesis-sim.org/userdocs/developer-package/developer-package.html

I am wondering (and hoping) if other people are interested in using
this system and contributing to its development.

-- 

Hugo


--

                    Hugo Cornelis Ph.D.

              Neurospaces Project Architect
                http://www.neurospaces.org/

                  Research Imaging Center
   University of Texas Health Science Center at San Antonio
                    7703 Floyd Curl Drive
                 San Antonio, TX  78284-6240

                    Phone: 210 567 8112
                      Fax: 210 567 8152




reply via email to

[Prev in Thread] Current Thread [Next in Thread]