You should be able to just push to it. Something like
hg clone http://repo.gem5.org/gem5 cd gem5 hg update -r <rev that is good/stable/whatever> hg push ssh://[email protected]/gem5-stable Ali On May 23, 2013, at 10:49 PM, Nilay Vaish <[email protected]> wrote: > What do we need to do to update the repository? > > On Thu, 23 May 2013, Ali Saidi wrote: > >> I >> On May 16, 2013, at 4:24 AM, Andreas Sandberg <[email protected]> wrote: >> >>> On 05/15/2013 08:36 PM, Nilay Vaish wrote: >>>> I think we should either remove the repo gem5-stable or put in place some >>>> policy regarding gem5-stable. As of now, there is nothing stable about it. >>>> If we want to keep it, I suggest that we do the following: >>> >>> I definitely agree with you, the stable repository needs to go. The stable >>> version is probably way more buggy than the other version and it is a >>> constant source of confusion for new users. >>> >>> I really can't see the point of a completely separate repository. All other >>> software projects I have worked on usually just have a stable branch for >>> each major version and tags for each minor release. If I remember >>> correctly, the Linux kernel has a working repository (kind of like our >>> working repo) and each major release gets its own branch (e.g., >>> linux-3.9.y), individual releases are tags (e.g., v3.9.1). Linux actually >>> has a separate repo where stable releases are maintained, but I think that >>> is just a way of reflecting the fact that there are different maintainers >>> of the stable repository. >> >> I also agree, but just as a warning, if you search the email achieves you'll >> find that we've come up with plans before. The issue has been sticking with >> them. I think even updating the stable repository every 3-4 months from the >> mainline would be reasonable, but it being over a year old isn't great. >> >>> >>>> a. update gem5-stable to gem5 every four months or so. Before updating, >>>> there would be a lean period of say 2-3 weeks when only bug-fixes would be >>>> committed to gem5. At the end of the period, gem5-stable would be updated >>>> to gem5. I propose updating gem5-stable on February 15th, June 15th and >>>> October 15th every year. We can have lean periods starting from 1st >>>> February, 1st June and 1st October. >>>> >> I'm quite happy with this approach. >> >> >>>> b. all patches that are committed to gem5 should be evaluated by >>>> developers as to whether they are bug fixes or not. If they are, and the >>>> bug is also present in gem5-stable, then those patches should also be >>>> committed to gem5-stable. I expect the extra work, in most cases, would be >>>> limited to applying the patch to gem5-stable and running the regression >>>> tests. >>> >>> I think we need a hybrid approach, let's call it c). Similar to a), we >>> could create a new stable branch (e.g., gem5-2013q1.x) 4 times or 2 times a >>> year. The only changes allowed to such a branch should be bug fixes >>> (preferably fixes that don't affect statistics). The branch is allowed to >>> cool for say 2 weeks before it is tagged for release (v2013q1.0). Once >>> enough bug fixes have accumulated, we just create a new release tag on the >>> branch. Merging bug fixes shouldn't be too hard since it would just be a >>> matter of cherry-picking changesets from the master branch. >>> >>> Unlike approach b), this approach wouldn't run the risk of diverging too >>> much from mainline, while at the same time providing stable releases at >>> regular intervals. >> I'm ok with this except that it's quite a it's more work, and we haven't >> even managed to just update the stable repository consistantly over the >> years. >> >> >>> We might want to take this opportunity to migrate our repositories to GIT. >>> In general, most people are more experienced at using GIT than Mercurial. >>> There are roughly 10x more GIT repos than HG repos [1], so it's probably >>> safe to assume that there is roughly 10x as many developers who know GIT. >>> We already have several internal GIT clones of gem5 in the group and I have >>> seen at least one other online (a port to Warped). Besides, it seems like >>> most tools have better support for Git (e.g., Jenkins has almost as many >>> new Git installations per months as there are Mercurial installations in >>> total). >> >> our fencing about git continues :) >> >> Ali >> >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
