Re: Pragmatic CVS

[Bob Proulx]

Mark Smith wrote:
> The project is several years old and has not been
> touched since 2005.  On inspection I found many big
> differences between the client sources and the client
> in the production environment, (i.e. several people
> have applied undocumented changes in production
> without updating CVS!).

Ah, the legacy corporate environment.  How I don't miss that! :-)

> For the client I checked out the latest (mainline)
> legacy code, applied lots of changes seen in
> production and re-designed several parts);

I would probably have committed all of the found changes into version
control before making additional changes.  (I think you committed
those changes on a different project line so that is okay.  But I
would probably additionally commit the "found changes" so that they
are safely documented too.)

> I then used this as a baseline to create a completely new client
> project called 'eclient'.

Sounds good.

> To follow the pragmatic guidelines I created a branch
> 'eclient_RELB_2_0', so work could continue on the
> mainline; however, I was the only developer so there
> were no other changes.
> 
> I was then ready to release so I created a branch
> 'eclient_RELV_2_0'.
> 
> So my first question is do you think it was correct to
> do it this way?

Asking if it is "correct" is not quite the right question because
there isn't one true correct way to do things.  But what you are
saying does follow one of the known good best practices.  It sounds
like you have done reasonable things.

Many people like to set up these branches at the time that they
release them so that they are prepared for future changes.  At the
time they are set up there usually isn't any changes there.  But by
preparing them at that time that they know how everything is supposed
to be it is fresh in the mind and everything makes sense.  Then later
in the event that they have changes to go in everything is set up for
it and everything is enabled to do those changes later.  Later when
the memory may have faded some and won't be quite as clear.  But
others would prefer to wait until it is needed and then create
branches as needed later.  It is a judgement call.  I prefer to set
them up earlier at the time of the release as you have done.

This is a document that you might find useful.  Look at the section
"Know when to create branches" for a discussion of your question.
This talks about svn in particular (ignore that) but the discussion of
branching is relevant to any version control system.  This one is
short and to the point and why I mention it.

  http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html

Here is another more detailed reference specific for CVS.

  http://cvsbook.red-bean.com/cvsbook.html#Branching%20Basics

> In this particular case, the mainline, the branch and
> the release code are all identical.

That is normal at that moment in time.

> So my next question is should I do some kind of merge
> (from a CVS administrative view) to synchronize the
> release changes into the mainline (even though there
> are no actual changes)?

No I think you are fine as I understand your description.  You have
just now branched and have no commits after the branch point.  There
isn't anything to merge until you have changes committed on a branch.

> The result is that I will need two different versions
> of some files (not ideal I know), and both versions
> will need minor updates in the future.
> 
> How do you recommend I should proceed?

I don't have any strong opinions here and so will leave that to others
on the list.  I think you will have bigger problems setting up the
build to be cross platform than dealing with the version control
system.

Bob