|
|
| Line 3: |
Line 3: |
| | <br /> | | <br /> |
| | | | |
| − | If you're not acquainted with svn revision numbering schemes, here are a couple of good-to-know points about SVN versioning.
| + | OpenSim uses Git for its source code repository. |
| | | | |
| − | 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.
| + | Active development usually occurs on the master branch, with occasional sub-branches for specific features. |
| | | | |
| − | Revisions are based on a revision before it, but that does not have to be the revision <em>immediately</em> before it.
| + | Release branches are named <version>-release. For example, 0.7-release is the 0.7 release branch. These release branches contain release candidates and bug fixes, as well as the final release. |
| | | | |
| − | 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.
| + | There are also 'post fix' branches, named <version>-post-fixes (e.g. 0.7-post-fixes). These contain bug fixes that were made to the formal release but haven't yet resulted in a release themselves. |
| − | | + | |
| − | 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.
| + | |
Active development usually occurs on the master branch, with occasional sub-branches for specific features.
Release branches are named <version>-release. For example, 0.7-release is the 0.7 release branch. These release branches contain release candidates and bug fixes, as well as the final release.
There are also 'post fix' branches, named <version>-post-fixes (e.g. 0.7-post-fixes). These contain bug fixes that were made to the formal release but haven't yet resulted in a release themselves.
