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
