Question about the repository layout

Hello IT-mill devs,

I have been doing some repository conversion tests, basically trying to convert the Vaadin repository from Subversion to Mercurial. The point of this exercise was to test if the history can be nicely converted, and to check the stability of Mercurial conversion tools. Long term goal is to possibly host a read-only mercurial mirror of the repository, since managing external patches before inclusion might be easier with Mercurial (we had a nice discussion about this with Ville when we met last week :).

Mercurial conversion needs to know the location of the branch, tag and trunk folders. I have figured out, that versions-folder == branches, releases-folder == tags, but I cannot seem to find the trunk? Do you generally branch the new version from the last version branch, or from some trunk-type branch? For my test conversion I have used folder versions/6.0 as trunk, but this doesn’t feel very stable solution, since it overlaps with branches (possibly confusing the conversion tool), and I’m not sure if the trunk can be moved after migration when new version branch is cut.

Any pointers or comments appreciated :slight_smile:

-Harri

Vaadin 6.0 development lives in versions/6.0 and is kept stable. All new developments will be done in branches that will eventually be merged to versions/6.1.

There are many reasons for this - some of the most notable are that this way trunk does not turn to a mess and one can actually use nightly builds fairly safely. Furthermore, integration of “good” commits from trunk (mess) to a “stable” branch is tricky and we often ended in a situation where the “stable” releases were tested less than the “unstable” trunk.

Thanks for explanation. So if I understand correctly, you use a model where you branch a new version branch from last version branch.

That is certainly understandable, and I’m certainly familiar with the problems of keeping the trunk stable. :slight_smile: However, have you considered using a model, where you automatically merge or “drop” changes from stable branches back to “trunk” or next? Developers could still work on the stable branch, which would also get testing focus, but external contributors would have a single target to base their patches on (the “trunk” or next).

We have used this model in the past with reasonably good success, and the merge process can be almost completely automated (using SVN merge tracking), barring conflict resolution which has to be done occasionally. Of course, risky stuff would have to be done in separate feature branches. Unfortunately doing features in separate branches is a bit sticky using Subversion, at least compared to other tools (such as Git or Mercurial) :frowning:

Yes.

Currently we are having own directories for minor versions 6.0, 6.1, … instead of just having them for majors 4, 5, 6, … The reason is that we are maintaining minors in parallel - 6.0.x maintenance releases will keep coming in stable versions/6.0 while we’ll do pre-releaes for the next release in versions/6.1

That is a really good point. All bug-fixes should be targeted against the stable versions (currently versions/5.4 and versions/6.0)

Because development branches are forked from stable version, they should either reroot or merge patches regularly from there. Lets say that I am preparing a new feature X. It should done in branches/1234_X where 1234 is a corresponding ticket number. The branch was made by svn copy from versions/6.0. When we push bugfixes to versions/6.0 I probably want to merge them to my development branch also. In some point of time we’ll start to integrate new features to versions/6.1. eventually I’ll merge all the changes from my dev branch to versions/6.1 and remove the completed feature branch.

Using git would help the above process a lot. We actually considered this, but decided to stay in svn as eclipse integration for git is still so weak. Also svn is fortunately learning from git in each version…