gnu-arch-users
[Top][All Lists]
Advanced

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

RE: [Gnu-arch-users] Re: Mixing star-merge and selective replay


From: Parker, Ron
Subject: RE: [Gnu-arch-users] Re: Mixing star-merge and selective replay
Date: Fri, 16 Apr 2004 10:15:12 -0500

> From: address@hidden

I haven't thought through the details, I'm not sure I actually know enough
about tla yet.  I am still learning, but this sounds like a candidate for
separate branches and possibly configs.  Please critique.

If multiple branches are used:
        project--mainline--1.0
        project--fork--1.0
        project--fork-local--1.0
        project--spoon--1.0
        project--spoon-local--1.0

Both fork and spoon could initially be tagged from mainline.  Likewise
fork-local from fork and spoon-local from spoon.  The *-local branches could
be the development branches and when something is ready to be shared with
the world it could be apply-delta'd into fork or spoon minus the
never-merge-this-elsewhere patches.

Using this, I believe that mainline, fork and spoon could all star-merge
from fork and spoon with out ever picking up the *-local only patches.  Also
fork and spoon could update from mainline and the *-locals from their parent
utensil.

The reason I mention configs is, if it were possible to isolate the *-local
changes to  a sub-project, then the appropriate sub-project could be brought
in with a config instead of branching the entire project.  

My thinking stems from where I work.  There are certain features of our
software that are only available internally.  For example we have various
tools for our quoters that allow them to see actual costs and the details of
our margins on a pre-engineered components, reports on the number of
engineering hours allocated to sub-components and yet other tools for
importing the data from the end-user file into our legacy engineering
systems.  

These tools could be worked on by separate groups and then only built as
part of an internal config as opposed to an end-user config, also in some
cases there may be a need for a regionally customized version of one of the
tools.  This too could be handled by a *-region branch and an appropriate
region config.  We would tend to merge the region branches in and use
runtime switching, but it wouldn't have to be done that way.

Like I said, I am still learning and there may be caveats I have not
foreseen in this approach.  So if you know more tla than I, please correct
and or critique my ideas.  I have not tested them only thought about how it
might be done.




reply via email to

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