StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The natural solution to your problem is branching. However if you have this scenario infrequently and are determined to avoid branches, you can put all your versions on the HEAD and set the tags accordingly.</p> <p>Lets say you have the following version of DatabaseFacade.java:</p> <pre><code>1.1: original version, which has the bug 1.2: version with new feature, which you do not want to release yet </code></pre> <p>You checked out 1.1 and made your bug fix, but - alas - you can't commit it because you are on a sticky tag. To solve it, do the following (I didn't test the code, but it should illustrate the idea):</p> <pre><code># backup file with fixes mv DatabaseFacade.java DatabaseFacade.java-fixed # revert to HEAD: remove the sticky-ness cvs update -A DatabaseFacade.java # get revision 1.1 (non sticky) cvs update -p -r1.1 DatabaseFacade.java > DatabaseFacade.java # commit it cvs ci -m "reverted to revision 1.1." DatabaseFacade.java # commit your file with fixes mv DatabaseFacade.java-fixed DatabaseFacade.java cvs ci -m "fixed BUG434" DatabaseFacade.java # restore the latest development version to HEAD cvs update -p -r1.2 DatabaseFacade.java > DatabaseFacade.java cvs ci -m "reverted to revision 1.2." DatabaseFacade.java # also fix the bug in the latest development version cvs ci -m "fixed BUG434" DatabaseFacade.java </code></pre> <p>So now DatabaseFacade.java will have the following versions:</p> <pre><code>1.1: original version, which has the bug 1.2: version with new feature, which you do not want to release yet 1.3: same as 1.1 1.4: your bugfix to 1.1 1.5: same as 1.2 1.6: version with new feature and bugfix </code></pre> <p>Now you can tag revision 1.4 for the new release:</p> <pre><code>cvs tag -r 1.4 LIVE-REL-2.5 DatabaseFacade.java </code></pre> <p>When you take this approach, you should make sure that none of your fellow developers runs a <code>cvs update</code> while you are "playing with the history", i.e. while either 1.3 or 1.4 is the latest on the HEAD.</p> <hr> <p>There is no benefit in switching to Subversion. It will not help you with these kind of problems. If you are seriously considering a different version management system, you should take a look at Mercurial or any other Distributed Versionmanagement System. <a href="http://hginit.com/top/00.html" rel="noreferrer">In Mercurial, merging is painless and easy, and so branching is commonplace and harmless.</a></p> <hr> <p>By the way: Since you are tagging your new files with bug-identifier-tags (e.g. "BUG434"), you might also want to tag any existing file related to that bugfix with the same tag.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload