Community
Participate
Working Groups
Simultaneous release aggregation files are currently in a CVS repository (/cvsroot/callisto). These need to be migrated to Git. I recommend aligning with an early milestone build. While we're at it, we might as well come up with a more timeless name for the repository. I assume that the actual migration piece will be relatively easy and that updating the build scripts will be the bigger challenge.
+1 for doing this ASAP. Not that this is super important for others, but was just about to automate the last step in my promotion process, send promoted drops to staging. The aggregator file is the only artifact I have in CVS and I'm not keen on developing a CVS automation just to find out a wekek later that it's obsolete ;-)
+1 for ASAP. I'm also curious. "Callisto" holds the build/agregation files for every release (I assume starting with Callisto). Based upon what I know/am hearing about Git and our project migration strategy, would it make sense to migrate only Indigo, and Juno as separate Git Repos? or would it be one repo where the latest release is forked at release time for the next train?
Given current priorities, this will have to wait.
I don't see why the importance changes, granted it is late in the game at this point to consider this for Juno, but the bug isn't specifically targeted for Juno. If I'm being asked to migrate our project repository out of SVN, I see no reason that this should be lower priority. In fact, I think the overall build migration should be migrated before the projects are asked to.
(In reply to comment #4) > I don't see why the importance changes, I'm just using the "priority" field to help reflect the workflow that I have to do things, not to say its "less important" ... is that wrong? I hadn't even noticed the pair of fields (priority and severity) had been renamed to "importance" in this version of bugzilla. Not sure what that's supposed to mean, and "importance" not listed in "help", but Priority and Severity are still defined as Priority Engineers prioritize their bugs using this field. Severity How severe the bug is, or whether it's an enhancement. If you think its confusing, or if I am inconsistent or out of line using the "priority" field this way, I'll change it back to "3" and manage my workflow via some other means. Thanks for helping to clarify.
Given your explanation it isn't confusing. However, we usually sort bugs based upon several criteria (importance/severity and targeted milestone for example). Since it looks like the possible targets haven't been updated for Indigo, Juno, or any Post-Juno milestones, I'd say you are doing the best you can. That said, I'd still like to see the priority raised Post-Juno.
I've began to investigate this migration, and thought I'd outline my ideas/findings in case others have comments or other insights. In no particular order: First, there's two things to do here: 1) migrate old projects and their history to Git, but 2) create some new projects which would not change from year to year, we'd just make persistent branches for past years, and 'master' would always be for "the current year". I propose the new "permanent" projects be named org.eclipse.simrel.build org.eclipse.simrel.tools org.eclipse.simrel.tests I propose the git repo itself be named "simrel". I propose we exclude all branches, since none of those are meaningful ... just branches created to experiment, or perhaps when someone first was joining for them to "try things" without risking the main branch. So, for these "old" ones, we would have only "master". I propose we exclude nearly all tags. I was thinking of excluding all ... but ... technically some of them have meaning, like "HeliosSR1" or similar, and while I doubt that type of info would be very useful in the future ... I'd hate to "lose" info from a Version Control System. Except, there are about 300 tags from the early days when we automatically tagged each build ... so lots of the form "v20080324-1000", etc. Those I'm sure are not useful or meaningful, and think we should exclude those no clutter up the new repo with "junk" tags. That would leave about 30 tags that have a some meaning (though, we've never been consistent on how to tag these, so ... not useful to "casual user". There are 26 projects in cvs to migrate. I propose we exclude one named org.eclipse.simrel.tests since it was never used, and conflicts with one of our anticipated new ones. I propose the 25 migrated projects be put in a folder named oldcvscallisto "under" the root of the repository, then the folder would be a peer of the 3 new ones we will be creating. I'm assuming "import existing projects" keys off the .project file when someone clones a repo to their local working space. Assuming that's true, I'd almost suggest we rename those .project files to .projectORIG so that for someone to see or get at these old projects, they would have to say "import as simple project" and then they could explore the old code. (Is this a weird thing to do? To "hide" projects form causal users, while leaving them there for those who really want/need to dig through the history of our Sim. Releases?) Ideally, we could do this migration before Juno SR1 (and before Kepler M1) but that means I'd only have about a week to do it. ... Might be possible ... I certainly have the cvs2git conversion automated, since I've done it about 20 times this weekend :) ... but, have not yet looked at "changing the build". Should be easy ... but ... hate to say that since I haven't looked at it yet. Comments welcome.
I've been thinking ... perhaps instead of trying to have a special directory in the simrel repo to hold "old history", it would be easier to (still have one directory, /gitroot/simrel and it would have two repositories simrelarchives.git to hold all the old history from cvs (still cleaned up, as described above) in case it was ever needed, but then have a new repo simrel.git that would hold the three new ("persistently named") projects? It would just be "all new", as we started, but soon have a Juno_maintenance branch in addition to master (for Kepler). I don't see much advantage to having old and new all together in literally the same repo. Comments welcome.
Having just completed a migration from svn to git myself, I can say that migrating repositories is definitely non-trivial - especially where there is a lot of "massaging" involved (which it sounds like there is in this case). Therefore it is important to verify the necessity of a "migration" first. I'm not certain that in this case it is needed - though for some it might be "nice". However, I am not familiar with the entire simrel process. From my perspective, though, I only need the latest build file for each currently active branch, and I don't really care much about history... It's not likely that I will need to go back to see what I used for say.. M5 of Indigo (though it may be needed for the simrel process as a whole). Also, since I haven't really started on Kepler yet, sooner is better to switch that waiting for a nice migrated repo I don't need. My understanding is that the old CVS and SVN repos will remain available as read-only repos indefinitely. In that case history is only needed where reviewing the past is a common or daily activity. In this case (simrel), I'm not sure it is, so I'd be inclined to start a fresh repo with everyone's "release" Indigo build file, then create a branch for Indigo maintenance. If you really want to be nice, you could add the latest build file for Kelper (if there is one yet) to master. Being harsh and cruel by nature though ;), I'd be inclined to have the teams merge the latest files for Indigo Maint, and Kepler themselves - since they'd need to verify contents anyway, should have them readily available locally, and the amount of work on their part is basically the same. For those reasons, it'd also be easier to have them do the updates and "get them right" than you anyway. For history, we simply rely on the old CVS archive. I'm sure the problem is bigger than I am seeing though, for instance I'm sure there are scripts and control files you use that I'm completely unaware of. I just thought I'd try to save you quite a bit of work and say I'd be happy if only the latest active build files were migrated (no history or past branches required).
Hi David, Stefan Winkler has written a nice article about our Git migration. Maybe you find some helpful hints.
(In reply to comment #10) > Hi David, Stefan Winkler has written a nice article about our Git migration. > Maybe you find some helpful hints. Oh, the URL of that article may help, too :P http://www.winklerweb.net/index.php/blog/4-eclipse/16-migrating-the-cdo-svn-repository-to-git
Thanks everyone for your comments. @Eric, yes, migrating the history is not as important as a "code" project, in the sense that no one will ever make a "patch build" on HeliosSR2, for example, but ... I still think the history is important and hard to tell who might need what when for what ever purpose. Just seems the professional thing required to do; more than "nice to have" but less than "P1". I am not sure CVS access will last forever and I have seen mentioned elsewhere there will not be public (anonymous) access. So ... I've done the work ... I'll migrate. But, am settling on the repo name of .../simrel/oldcvssimrelprojects just to make it real obvious. More important, as I've played with migrating the build, and thinking about it more, I think the three "permanent projects" would best be their own, relatively independent repositories, all still under /gitroot/simrel. My first thought is to put the "code" directly under the repository root, instead of "subdirectories" of exactly one project. Not sure if this matters or limits anything? Let me know if anyone knows if that's a really bad thing to do. org.eclipse.simrel.build.git This is the one that changes often, modified by many people, and would have important persistent branches, such as Juno_maintenance. org.eclipse.simrel.tools.git This one does not change often, and not by many people (just me :/) so doesn't make much sense to make everyone "load" it as they clone the repository they need for .b3aggrcon files. And ideally, there would be little branching required. The same version/branch should be able to build Juno, Kepler, and beyond. As long as the general build mechanics stay the same. org.eclipse.simrel.tests.git This one is like "simrel.tools" with an additional consideration ... my fantasy is this functionality might move to Dash someday, to make it easier, and more obvious, that all projects can use these "repo tests" in testing their own builds. So, kind of makes sense to keep separate, and with luck it will be (relatively) short lived.
Sanity check: I've been using cvs2git tool to do my local "test conversion" and according to docs, by default it should create authors of "cvsid <cvsid>" but instead it seems to be making author fields of "cvsid <>". I assume this is not problematic? That it is what is in "cvsid" that is checked if "valid committer". Just thought I'd mention it, in case any of you git or conversion experts smell anything bad.
Webmasters: I see the instructions at http://wiki.eclipse.org/Git#Creating_a_new_repository so to create repos I will use something like initrepo /gitroot/simrel/org.eclipse.simrel.build.git I assume at that point, I'd be the owner (if not also the "group") so I could copy to it, delete it (if I decide to redo), set up config/hooks etc., as desired? I'm partially asking since "simrel" is not a normal, official "Eclipse Project", per se ... so ... I do not know if anything in "initrepo" is tied to projects/committers database? I'm guessing eventually we'd set group owner to "callisto-dev" group ... unless you wanted to bother to "copy" that linux group to "simrel-dev" (and eventually remove callisto-dev) just so the "simrel" name all matches up? Most important, is creating it enough to get it into "cgit"? I ask since part of our build depends on bootstrapping using cgit so wanted to be sure that was "good to go" right away. Thanks for any answers, advise, tips. Otherwise, hold on to your hat! :)
I'm sure the webmasters read all bugs :) ... but, in case not, I've added to CC list, so they can better answer comment 14.
> initrepo /gitroot/simrel/org.eclipse.simrel.build.git > > I assume at that point, I'd be the owner (if not also the "group") so I > could copy to it, delete it (if I decide to redo), set up config/hooks etc., > as desired? We'd likely set it up with yourself as the owner, callisto-dev as the group, and no update hooks since we can't tie it to a project. > Most important, is creating it enough to get it into "cgit"? Yep.
I've done the conversion, so /cvsroot/callisto can be put in "read only" mode. The new git versions (and newly renamed) repositories can be seen at http://git.eclipse.org/c/simrel/ with the most important (that is, the one that most people will load into their IDE is the repo at http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/ Or, for your IDE, clone ssh://<userid>s@git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git There is, already, a Juno_maintenance branch to use for Juno SR1. master will be for Kepler. Some of you might try committing a non-essential change, just to make sure it is possible. I have applied the same "pre-receive" hook that prevents people from deleting tags or branches, etc., ... except, you can have your own <userid>/somename branch and later delete that ... if you ever felt a need for it (though, I'd think it'd be rare you'd need your own persistent branch). I've opened bug 386655 to cover the documentation effort, and will count this one as fixed.
(In reply to comment #17) > I've done the conversion, so > /cvsroot/callisto > can be put in "read only" mode. Done. -M.
