Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Harrison, Andrew wrote: > Development then went on separately for the two branches. No commits were > done on the trunk. The time to merge the two developments is now > approaching, and the idea is to merge them both into the trunk and future > development will be done on the trunk. In preparation for this I did a > checkout on the trunk and have found a couple of problems. > > 1. Some eejit has mistakenly committed changes to the trunk, rather than to > the development branch. Is there an easy way to roll back these changes, > rather than go through each file and delete revision 1.2? If you're sure the changes in those files could be discarded, you could apply a technique called "reversion". Look here for a description of how to do this using WinCvs (also contains a link to the equivalent commandline instructions): http://cvsgui.sf.net/newfaq.htm#reversion . > 2. When I get the 'HEAD' revision, or do not specify a tag to get (which I > think should do the same thing?) on some files it gets the latest on the > Dev1 branch, rather than getting the latest on the trunk. HEAD will get you the latest revision on the "default" branch for a file. In 95% of the common cases this is the trunk. However, if you initially put the files into the repository by means of the Import command, the default branch will be set to the 1.1.1 vendor branch. Only when you commit another revision on top of that (without any sticky branch tags active) will the default branch be reset to the trunk (and the newly committed revision will consequently become 1.2). You could also manipulate the default branch using the cvs admin -b command but this undocumented and therefore not recommended unless you absolutely know what you're doing. If you however use the Add command to put files into the repository, the default branch will be the trunk right from the start. Updating without specifying a tag or branch, will get the latest revisions from the _current_ branch, i.e. the one a working copy is currently updated/checked out on. Note that after explicitly updating to HEAD, you could not commit any changes to these files as the HEAD tag would have become sticky and is not a branch specifier. You should probably use cvs update -A instead (aka "reset sticky options"). > Looking at the > ",v" files on the repository the difference seems to be the following: > > Files that get the latest on the trunk start: > head 1.1; > access; > symbols > > But files that get the latest on the Dev1 branch start: > head 1.1; > branch 1.1.1; > access; > symbols > > Can anyone tell me what the extra branch line means, and how it is likely to > have got there on some files and not on others? Based on what I wrote above my assumption is that the files that update to the trunk were either added only after the initial import or are those that already have a trunk revision (i.e. the ones you mentioned at the beginning). > Also, what can I do about this? You shouldn't really have to care. If no sticky tag/branch is active in your working copy then the next commit will go to the trunk no matter what. Hope this helps. -- Oliver ---- ------------------ JID: ogiesen at jabber.org ICQ: 18777742 (http://wwp.icq.com/18777742)