Re: Pragmatic CVS

[Mark Smith]

--- Bob Proulx <address@hidden> wrote:

Thanks very much for your reply Bob ...

> 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 recorded my findings in new project documentation I
wrote (and checked in to the new project I created);
but I also see your point here.

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

OK, on reflection that is quite an open question :)

> 
> 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

Thanks Bob, I'll have a read tomorrow.

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

OK, at this point all the current work is tagged and
checked in.  I can now release anything checked out,
rm –rf my work area and go on holiday.

Now back from holiday I want to make two sets of
changes, one to extend the current AIX version and one
to migrate to Linux.

I think the point (that I may be blowing out of
proportion) is what (tag) should I check out for each
set of changes, what kind of tag and/or branch (if
any) should I use when changes are ready to be checked
in; and finally what (if anything) can I or should I
do about merging changes?

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

I'll have a read of the links you sent about branching
and tagging; I'm not too worried about the builds.

Thanks again for your feedback Bob, much appreciated.

Mark.



      
____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping