Community
Participate
Working Groups
We should move our code-base to Git. There are several reasons for this: 1. It's easier to work with since Buckminster's support for Git is based on egit/jgit and all code that is involved has been approved by the Eclipse EMO. This means that no external repositories are needed. 2. Git's distributed model is a vast improvement over the centralized model. 3. The git repositories at Eclipse are mirrored at GitHub [1]. This gives us better visibility and makes it easier to fork and provide patches. 4. Our buildsystem already supports Git. It's just a matter of switching a URL in the RMAP. 5. Today, egit has reached a maturity that is pretty good. Perhaps it's already better than both Subversive and Subclipse. One thing is for sure, egit/jgit are far more active and the response from the team is excellent. Git feels like a much safer bet going forward. [1] https://github.com/eclipse
Nice! http://wiki.eclipse.org/Git#My_Eclipse_project_wants_to_use_Git
Great! I've already used git with the buckminster code base through git svn to contribute the odd patch or two. Moving to "native" git would definitely be an improvement. I guess with git's lack of an incrementing revision number, you'll be switching from the SVN revision scheme to a timestamp based format for your version qualifiers? In that case I'd like to suggest consistently tagging every release - preferrably with the full release version+qualifier. Because from my experience with other projects I find it quite hard otherwise to get the source for exactly the version I'm currently running.
+1 my git/egit surprising moments have been far fewer and easier to work around than when subclipse decides to screw things up... Sad to see the nice SVN revisions qualifiers go away. Any ideas for a self managing replacement?
http://stackoverflow.com/questions/4120001/what-is-the-git-equivalent-for-revision-number It doesn't really make sense to have a revision control number within git... in the SVN sense. You can use git-tag to tag things in combination with git-describe for a readable version number.
The revision numbers has to go, that's clear. And we cannot use git's revisions in a version qualifier either since they are not chronological. The revision that we use as the qualifier today is per project, i.e. it reflects the latest revision for any change in the project, or for features, the latest revision for the feature itself, or any included feature or bundle. I really want to avoid bumping qualifiers on all projects just because a change was made to one of them since that will make p2 download just about everything the next time an update is requested. I still want to make it easy for everyone to check out the correct source. I'm not sure what the best solution for that would be at the moment. Enforcing chronological tags would be one way I guess, and then find the tag that correlates to the last change for each project.
I've thought some more about the version qualifiers and here is a proposal. For qualifiers: - All qualifiers will use timestamps in the form yyMMdd-HHmm - In case of bundles, the timestamp will reflect the last commit that affected something beneath the project root. - In case of features, the timestamp will either reflect the last commit beneath the project root, or the last timestamp of one of the included features/bundles. Latest timestamp wins. I think that should be fairly easy to find the exact right source for a bundle. It can always be found in the commit that has a timestamp equal to the one reflected in the qualifier for the given branch. If you want the source for several features/bundles, then the last timestamp found among them should be used. The only time that breaks is when you look at a partially updated install. At such a time there is no single revision that will reflect the correct source. So how do you know which branch to use? That too should be easy. Even if we're not on the train, we still follow it with our releases and branches. At present, we have two branches, the helios-maintenance branch and the trunk. The former has gone more or less stale after Helios SR2. Once Indigo is out, we will create the indigo-maintenance branch and continue working on trunk (or using Git lingo, on master). Our version numbers should reflect which one to use. All our Indigo projects will use 1.4.x. All prior to that are Helios and next years release will most likely be 1.5.x. So, no immediate need for tagging, nor to use tags in the qualifiers. The "tag" is the timestamp of the commit. Thoughts?
(In reply to comment #1) > Nice! > > http://wiki.eclipse.org/Git#My_Eclipse_project_wants_to_use_Git I see that it's recommended to use one git repository for each logical unit. "Typically, one Git repository (.git) is created for each logical unit, or grouping of code -- a plugin, a connector, a component, and so on." The Buckminster code base is reasonably fine grained. We have +70 projects today (features, plug-ins, test code, and releng) and storing each project in it's own git repository would make it somewhat cumbersome to obtain the code base as a whole. Dividing the code base into larger chunks like 'common', 'pde-support', 'svn-support', etc. might perhaps give us some benefits but I'm not sure about that either. Although it's many projects, it's really not that much code so cloning should be relatively fast anyway. Are there any other cons in treating Buckminster as a whole as a "logical unit" and store all of it in one single git repository?
Starting with one large repository is fine. This is pretty much what the linuxtools project did (http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/tree/) The downside (or upside) to that approach is that you'll be aware of all the changes that are happening in the tree.
(In reply to comment #7) > (In reply to comment #1) > Are there any other cons in treating Buckminster as a whole as a "logical unit" > and store all of it in one single git repository? Isn't there a big con if they are broken up. With 70+ project in separate repositories, isn't there 70+ separate pull/push if say, you perform a refactoring that affects them all... Can you do all at once? In one transaction ? So, I guess that "logic unit" should be interpreted as "what you would typically have visible when refactoring".
(In reply to comment #9) > So, I guess that "logic unit" should be interpreted as "what you would > typically have visible when refactoring". I like that interpretation. And it speaks for keeping Buckminster as a whole in one big repository.
The Buckminster code base (all revisions since the helios-maintenance branch was created a year ago) has now been converted into our new Git repository. It can be reached at: Clone git://git.eclipse.org/gitroot/buckminster/buckminster.git ssh://git.eclipse.org/gitroot/buckminster/buckminster.git http://git.eclipse.org/gitroot/buckminster/buckminster.git
