--- Bob Proulx <[EMAIL PROTECTED]> 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
