On Mon, 25 Feb 2019 at 20:57, Vladimir Sitnikov <[email protected]> wrote: > > 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)
Given that SVN history for tags/testhead and tags/test are basically identical, I think that must be a problem in the SVN->Git conversion. Here is the commit that created test: A /jakarta/jmeter/tags/test (from /jakarta/jmeter/tags/v2_5_RC3:1167593) And testhead: A /jakarta/jmeter/tags/testhead (from /jakarta/jmeter/tags/v2_5_RC3:1167595) This look identical to me apart from the source revision. > 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. Eventually. But it may take a while. Meanwhile there is a spurious 5.2-snapshot which is older than the 5.1-snapshots. But if there is no further minor version, it won't be replaced. > 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. I don't understand. > 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. If the build.xml is not updated in a timely fashion, then I agree that 5.1-SNAPSHOT may contain some bits of 5.2. But that does not matter, because once the version is updated to 5.2-SNAPSHOT, that will become the latest snapshot. If the release procedures are followed, there should be no spurious commits in the snapshot. > Both cases are bad, however current 5.1-SNAPSHOT is worse than a > theoretical 5.2-SNAPSHOT. No, it's just the reverse, because 5.2-SNAPSHOT is later than 5.1-SNAPSHOT so it 'hides' the later builds which are tagged 5.1-SNAPSHOT. Remember that the version has to be down-dated if the release fails. > 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. This is basically what happens currently, except we use SVN tags. > 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) At this point master has a release version, which is a no-no as already explained. > 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 The above is wrong - what happened to 5.2-SNAPSHOT? > sebb> The following are SVN test commits, and could be deleted now > > Ok, I've added them to the script. I think they should just be removed from SVN. > 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. OK for new branches. But it's too late to change existing branch names - that would be confusing, and there may be references to them. > Frankly speaking, I was puzzled by docs-x.y naming for the branch that > contained both sources, docs and javadocs. It's documented on the Wiki: https://wiki.apache.org/jmeter/ReleaseCreation > Vladimir
