[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Implementing Branches
Re: Implementing Branches
Fri, 15 Jun 2001 17:18:27 -0400
On Fri, Jun 15, 2001 at 01:00:24PM -0700, Anita Chacko wrote:
> We have a new design for a separate implementation
> basically of the same project.There will be new
> modules added in this and some old modules will
> undergo changes of structure;some will be split into 2
> or 3 modules and so on.I am not able to figure out
> which approach to take
> 1.To create many branches -- one for each module and
> ask developers to place all files and directories
> related to this implementation in these.In this
> case,will there be any problem merging them back on
> main branch?
My immediate reaction: NO NO NO!
A more considered reaction :-) why are you considering this? I'm
asking seriously; to create many branches probably isn't the
answer, but figuring out what *is* requires properly
understanding the question, ie. your needs.
> 2.To create an empty branch(Is this possible at all?)
> and add the new directories and files(and many
> existing directories from the main branch)
Possible, but (a) hard -- you'd have to create the branch and
then delete everything on it; (b) it's icky -- see (a); and (c) I
wonder -- again, I'm asking seriously -- why you want to.
> 3.To create a new repository for the implementation.
I'll come back to this in a minute.
4. Create one branch (not many) for the new implementation. This
will initially be a clone of the trunk at the time you create
it (if you use "cvs tag" in an up-to-date sandbox), or of the
latest stable release (if you use "cvs rtag -rXXX"). Let it
stay that way; people can add and delete files or directories
(More generally, a newly-created branch is always a clone of
*something*, but just what it's a clone of depends on whether
you use tag or rtag, and with what options. It can easily
start as a clone of some other branch. But since you say
you've never worked with branches, I'm assuming the trunk is
all you've got.)
If you create a new repo, (3), you won't have to contend with all
the cruft from the old implementation, but bug fixes made in one
code base won't be as easy to propagate to the other one, and if
you later want to merge them, your job will be harder. Then
again, if the two diverge very widely, these things will be hard
The choice between (3) and (4) probably comes down to how heavily
your new implementation will be based on the old one. If you
expect to start with the old one and modify it, do (4). If you
expect to start with a clean slate (and not keep much old code),
If you'll start with a clean slate but then bring a significant
amount of stuff over from the old implementation, that's a hard
one. I'd lean towards (4) ... but then, I'm a bit of a purist.
I'd be interested to hear others' opinions too.
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. address@hidden
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)