|
|
(5 intermediate revisions by 3 users not shown) |
Line 1: |
Line 1: |
− | __NOTOC__
| + | #REDIRECT [[Branches]] |
− | {{Template:Quicklinks}}
| + | |
− | <br />
| + | |
− | | + | |
− | If you're not acquainted with svn revision numbering schemes, here are a couple of good-to-know points about SVN versioning.
| + | |
− | | + | |
− | In an SVN repository, the 'revision' is a discrete version of the software. But; the revision <em>number</em> is <span style="text-decoration: underline;">not</span> an indication of sequential functional increment.
| + | |
− | | + | |
− | Revisions are based on a revision before it, but that does not have to be the revision <em>immediately</em> before it.
| + | |
− | | + | |
− | The revision number counter is global to the svn repository, hence it is upped whenever somebody does something within the repo, regardless of what branch the thing happens to.
| + | |
− | | + | |
− | An example:
| + | |
− | <ul>
| + | |
− | <li>I commit something to <em>trunk</em>, the rev number is upped to, say, <strong>1337</strong>, and my new version is given that number.</li>
| + | |
− | <li>I now branch trunk into <em>/branches/mybranch</em>. I do this by doing a remote copy of trunk. This copy of trunk, although identical to 1337, is a new version and is thus given the revision number <strong>1338</strong>, the first revision on the new <span style="text-decoration: underline;">branch</span>.</li>
| + | |
− | <li>Now I commit a number of changes to trunk, spinning past <strong>1339</strong>, <strong>1340</strong>, <strong>1341</strong> and <strong>1342</strong> - each being separate <span style="text-decoration: underline;">versions</span> but on the <span style="text-decoration: underline;">branch</span> called <em>/trunk</em> (think of it as paths)</li>
| + | |
− | </ul>
| + | |
− | Now, if I commit some minor change to <em>/branches/mybranch</em>, what revision number will it get? You guessed it - <strong>1343</strong>.
| + | |
− | | + | |
− | If I now commit something to <em>/trunk</em> again, it will get <strong>1344</strong>. I then commit something to the really really old branch <em>/branches/reallyoldbranch</em> that was based on, say, revision 666. It will now get <strong>1345</strong>.
| + | |
− | | + | |
− | So, my point is: you should never talk about revision numbers when you're trying to convey an idea of some kind of sequential advancement of state.
| + | |
− | | + | |
− | Ie, in my example, 1344 is probably the one reflecting the most development, 1343 is essentially based on 1337 and 1345, currently the highest rev number, could basically be six months old, with just a minor modification.
| + | |
− | | + | |
− | Now on to tags:
| + | |
− | | + | |
− | Trunk, branches and tags are really all one thing: paths. The only real difference is by convention: there is a certain path called <em>/trunk</em> that serves a certain purpose, namely to be the focal point for developers. There is a certain name used for paths other than trunk, and that is "branches". Some branches <em>by convention</em> aren't meant to be modified, but serve as snapshots of a point in time - they are called "tags".
| + | |
− | | + | |
− | But to the server, they are all revisions along different link paths. There is really nothing stopping you from committing to a tag - it's just the svn client will be reluctant to do so, as it's aware of the convention.
| + | |
− | | + | |
− | Keep this in mind, when referring to a 'revision' - it might be on a totally different path, so be sure to mention what path you're really talking about. specifying "<em>trunk, between revision 1343 and 1780</em>" or "<em>0.6.2 post-fixes, between revision 1764 and 2006</em>" again lets you compare revision numbers to indicate advancement of state.
| + | |
− | | + | |
− | Also, don't tell people to check a certain revision out, unless you mean <span style="text-decoration: underline;">exactly</span> that code snapshot. If you want them to check out a certain version, tell them the logical path ("/branches/0.6.5-post-fixes") to it instead.
| + | |