info-cvs
[Top][All Lists]
Advanced

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

Re: Implementing Branches


From: Eric Siegerman
Subject: Re: Implementing Branches
Date: Fri, 15 Jun 2001 17:18:27 -0400
User-agent: Mutt/1.2.5i

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.

Another possibility:

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

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

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),
do (3).

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)



reply via email to

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