sebb> What do you mean by "root commit"? In Git every commit has 0..n parent commits. The most typical case is 1 parent which represents a simple history like a->b->c Two or more parent commits mean we deal with a merge commit.
Commit can have 0 parents, and it means it is "Initial" commit. That is the one that does not have previous history. Git repositories can have multiple unrelated histories (e.g. multiple root commits, and each one could evolve into its own unrelated history) sebb> Or 5.2-SNAPSHOT may never be replaced, if the next version is 6.0-SNAPSHOT. See: 5.2-SNAPSHOT will likely be replaced provided the subsequent version is 5.2. On the other hand, current build.xml produces 5.1-SNAPSHOT, and it is extremely unlikely that we would ever produce 5.1-SNAPSHOT for a good reason. That means 5.1-SNAPSHOT is broken forever unless someone redeploys a proper 5.1-SNAPSHOT (the one that does not include bits of 5.2), or removes 5.1-SNAPSHOT from the repository. Both cases are bad, however current 5.1-SNAPSHOT is worse than a theoretical 5.2-SNAPSHOT. However, there's no point in discussing that. I think you missed my point: I suggest to create release branches, and set non-snapshot version there. Then: 1) master would not be affected by release branches 2) As soon as release branch settles down, master is promoted to the relevant commit (non-snapshot one) 3) Then we increase the version and add SNAPSHOT again to the master branch. In other words, master branch history would look like 5.1-SNAPSHOT 5.1-SNAPSHOT 5.2 <- this commit is tagged with v5.2 5.3-SNAPSHOT 5.3-SNAPSHOT sebb> The following are SVN test commits, and could be deleted now Ok, I've added them to the script. sebb> Again, IMO it's too late to change this now I don't think it's to late to change branch names. At least, we can start using release-X.Y for release branches. Frankly speaking, I was puzzled by docs-x.y naming for the branch that contained both sources, docs and javadocs. Vladimir
