| Summary: | Git repositories collection (git.gentoo.org, NOT overlays) | ||
|---|---|---|---|
| Product: | Gentoo Infrastructure | Reporter: | Robin Johnson <robbat2> |
| Component: | Git | Assignee: | Gentoo Infrastructure <infra-bugs> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | enhancement | CC: | daltonmatos, dberkholz, halcy0n, hwoarang, ikelos, pchrist, peper, rbu, spatz, sping, vorlon |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://sources.gentoo.org/gitweb/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
svn2git rules for portage
svn2git rules for portage v2 svneverever output on portage history up to r15726 svn2git rules for portage v3 (without gentoo-stats) svn2git rules for portage v3 (gentoo-stats only) svn2git ruleset for converting the gentoo-syntax repo to 2 git repos, {gentoo,eselect}-syntax svn2git ruleset for converting the gentoo-syntax repo to 2 git repos, {gentoo,eselect}-syntax authors-map for gentoo-syntax |
||
|
Description
Robin Johnson
2007-10-16 07:45:03 UTC
vapier: you were interested in a repo for some patch stuff? name: glsamaker
type: a, there's a local git repository already. I could either send it to
you, or push it upwards if you set up the rights.
access: py, rbu, vorlon (more later)
git.overlays would allow security to add devs in recruitment to edit the code, so I believe that is better suited. what would be really nice is if devs could create/destroy their own repositories in a name spaced world: /$USER/ then we wouldnt have to go and bug infra every time we wanted you to just run `git init` Bah, obviously the wireless I was using sucked, and my reply to here about the glsamaker creation didn't actually get posted. It is done already, you can push to it now. btw, any word on commits mailing lists ? name: pr-private type: a access: read-none, rw-PR Purpose is storing login info for sites like freshmeat. OK, I'm leaving a comment on the damn bug because I was asked to do so, even though I don't understand why... so here's the damn comment... (b) convert existing CVS or SVN to Git Please add some information about the repository. name: lu_zero type: b access: myself for now name: eselect type: b access: ffa name: "xserver" type: (c) import repositories from somewhere else access: RW for "x11", R for anonymous I'd like to clone git://anongit.freedesktop.org/git/xorg/xserver and add gentoo-only branches there to share patches with upstream. Thanks (In reply to comment #7) > name: pr-private > type: a > access: read-none, rw-PR > Purpose is storing login info for sites like freshmeat. Done. git.gentoo.org:/var/gitroot/pr-private.git/ (In reply to comment #9) > (b) convert existing CVS or SVN to Git > > Please add some information about the repository. > name: lu_zero > type: b > access: myself for now lu_zero why must your repo be on git.gentoo.org vs. the git.overlays.gentoo.org hardware? Is there anything that must be private to it? Dev overlays generally goes on the latter box. Please clarify. (In reply to comment #10) > name: eselect > type: b > access: ffa Again, same comment, if it's going to have non-developers having access, it MUST be on the git.overlays hardware. Please clarify. (In reply to comment #11) > name: "xserver" > type: (c) import repositories from somewhere else > access: RW for "x11", R for anonymous > > I'd like to clone git://anongit.freedesktop.org/git/xorg/xserver and add > gentoo-only branches there to share patches with upstream. Created on git.overlays.gentoo.org per clarification on IRC. "x11" group is in git.overlays and does contain non-devs. (In reply to comment #14) > (In reply to comment #10) > > name: eselect > > type: b > > access: ffa > Again, same comment, if it's going to have non-developers having access, it > MUST be on the git.overlays hardware. Please clarify. With ffa i meant devs, as I don't think any non-devs want access anyway. But whichever is easier for you. i think the server is missing some automated hooks or something $ git clone http://git.overlays.gentoo.org/gitroot/proj/sandbox.git Initialized empty Git repository in /root/sandbox/.git/ fatal: http://git.overlays.gentoo.org/gitroot/proj/sandbox.git/info/refs not found: did you run git update-server-info on the server? vapier: fixed, but please use the correct bug. this bug is NOT for git.overlays. I 'd like a git overlay too if possible :) name: nemesis type: a access: just me, no read or write access for nobody else. Purpose. For university or individuals projects I am working on. Thank you hwoarang: if it's for Gentoo stuff, then sure, but it's still not totally personal use. If you want personal use stuff, go and use github or just run your own git repos, it's pretty easy to do so, just get yourself a box somewhere and install gitosis-gentoo. Ah ok :). I misunderstood the purpose of gentoo git repositories. Thank you for proposing me alternative solutions :) Here I am once again I 'd like to have a git overlay for packages that are not mature enough to be on portage name: hwoarang type: a access: write access just me for now, read access to everybody Many thanks hwoarang: err, your asking for an overlay? This is not the place to ask for overlays. Read the frontpage of git.overlays.g.o for those. Meh... Sorry I failed again :) Thanks for pointing me to the correct direction again name: portage type: b access: zmedico, grobian, vapier, solar (anybody with current svn access) name: devmanual type: b - svn.gentoo.org/var/svnroot/devmanual access: all that currently have access to commit to the svn repo (In reply to comment #26) > name: devmanual > type: b - svn.gentoo.org/var/svnroot/devmanual > access: all that currently have access to commit to the svn repo Completed: git+ssh://git.gentoo.org/var/gitroot/devmanual.git Access to the SVN is disabled now. zmedico: do you still want Portage SVN moved to Git? (In reply to comment #28) > zmedico: do you still want Portage SVN moved to Git? Yes, please. (In reply to comment #27) > (In reply to comment #26) > > name: devmanual > > type: b - svn.gentoo.org/var/svnroot/devmanual > > access: all that currently have access to commit to the svn repo > Completed: > git+ssh://git.gentoo.org/var/gitroot/devmanual.git > > Access to the SVN is disabled now. > One thing I didn't think of...are the hooks still in place to update the static site when commits occur? (In reply to comment #27) > (In reply to comment #26) > > name: devmanual > > type: b - svn.gentoo.org/var/svnroot/devmanual > > access: all that currently have access to commit to the svn repo > Completed: > git+ssh://git.gentoo.org/var/gitroot/devmanual.git Can I sync the new repo? I tried `git clone git://anongit.gentoo.org/devmanual.git` but it didn't work. > Access to the SVN is disabled now. Will it be removed from sources.gentoo.org? Will someone add a warning that this repo is out of use? (In reply to comment #30) > One thing I didn't think of...are the hooks still in place to update the static > site when commits occur? The only hooks on the SVN side for devmanual are ones that send emails, there are none that update the site. I'll look deeper at the site scripts in the next day or two (it's due to moving onto a newer cfengine box anyway) (In reply to comment #31) > Can I sync the new repo? I tried `git clone > git://anongit.gentoo.org/devmanual.git` but it didn't work. Fixed. Beware that anongit does NOT permit commits, and runs lagged behind the actual git.gentoo.org box. > > Access to the SVN is disabled now. > Will it be removed from sources.gentoo.org? Will someone add a warning that > this repo is out of use? Not presently. At some point in the future when sources.g.o is redone, there will be a sub-page for retired repos. (In reply to comment #29) > (In reply to comment #28) > > zmedico: do you still want Portage SVN moved to Git? > Yes, please. The root of the Portage repo is not laid out for a single project, so this is going to be a challenging conversion. rev 1-1888 = normal trunk dir rev 1890 = trunk moved to main/trunk rev 1891 = main/branches main/tags added So I'm proposing the following: Repo #1: Portage, with 1-1888 following /trunk, 1890+ following main/. Repo #2: /gentoo-stats Repo #3: /eclass-manpages Repo #4: /private/antarus Repo #5: /private/blubb (maybe merge the .../branches/ bit to repo #1) Repo #6: /private/genone (jstubbs and vapier never used their /private/ repos) (In reply to comment #34) That's all good, except for Repo #1: Portage. This repo should be 1941-2261 following main/branches/2.0, and 2262+ following main/trunk. Also, is Repo #1 going to include the branches which branched from main/trunk? The most important of those is branches/prefix which branched from main/trunk in 2290. branches/2.1.7 and branches/2.1.6 would also be nice to have, but they're less essential. Honestly, we could probably skip the conversion of Repos #2 through #6, especially if we are planning to keep around the old subversion repo in readonly mode (are we?). The only parts that have had any recent activity are main/trunk, branches/prefix, and branches/2.1.7. These are the only parts that I see as being essential to have converted (ideally with the branches being converted to real git branches). (In reply to comment #35) > (In reply to comment #34) > That's all good, except for Repo #1: Portage. This repo should be 1941-2261 > following main/branches/2.0, and 2262+ following main/trunk. > > Also, is Repo #1 going to include the branches which branched from main/trunk? > The most important of those is branches/prefix which branched from main/trunk > in 2290. branches/2.1.7 and branches/2.1.6 would also be nice to have, but > they're less essential. I was going to bring in ALL of the tags and branches for Portage. HEAD for 1941-2261 would be the actual main/trunk, and the main/branches/2.0 would be in a branch named 2.0. > Honestly, we could probably skip the conversion of Repos #2 through #6, > especially if we are planning to keep around the old subversion repo in > readonly mode (are we?). Yup, we are. (In reply to comment #36) > I was going to bring in ALL of the tags and branches for Portage. HEAD for > 1941-2261 would be the actual main/trunk, and the main/branches/2.0 would be in > a branch named 2.0. It seems like the history will be a little screwy since main/branches/2.0 got moved to main/trunk in rev 2262. If that doesn't choke up the conversion that I guess that's okay. As long as the history since rev 2262 is accurate then I'll be happy. (In reply to comment #34) > (In reply to comment #29) > > (In reply to comment #28) > > > zmedico: do you still want Portage SVN moved to Git? > > Yes, please. > > The root of the Portage repo is not laid out for a single project, so this is > going to be a challenging conversion. > rev 1-1888 = normal trunk dir > rev 1890 = trunk moved to main/trunk > rev 1891 = main/branches main/tags added > > So I'm proposing the following: > Repo #1: Portage, with 1-1888 following /trunk, 1890+ following main/. > Repo #2: /gentoo-stats > Repo #3: /eclass-manpages > Repo #4: /private/antarus > Repo #5: /private/blubb (maybe merge the .../branches/ bit to repo #1) > Repo #6: /private/genone > (jstubbs and vapier never used their /private/ repos) This sort of conversion (with that move of trunk at r1890 handled properly, and /private/foo being branches) is doable with git://gitorious.org/svn2git/svn2git.git, if you'd rather keep things in one repo. Has anyone given svn2git a try on this very case (portage), yet? (In reply to comment #39) > Has anyone given svn2git a try on this very case (portage), yet? Nope, haven't had time to. If it's going to bring in ALL of the history, branches and tags properly, then go for it. Created attachment 221899 [details] svn2git rules for portage (In reply to comment #34) > So I'm proposing the following: > Repo #1: Portage, with 1-1888 following /trunk, 1890+ following main/. > Repo #2: /gentoo-stats > Repo #3: /eclass-manpages > Repo #4: /private/antarus > Repo #5: /private/blubb (maybe merge the .../branches/ bit to repo #1) > Repo #6: /private/genone > (jstubbs and vapier never used their /private/ repos) I made a rules file to teach a tweaked version of that to svn2git, see attachment. My call to svn2git was: # time svn2git --identity-map ../portage-author-map.txt --rules ../portage-svn2git-rules.txt --add-metadata ../portage-anon-svn-repo-dump/ dev-util/svn2git ebuild is in the sping overlay [1]. The used author map is up at [2]. IMPORANT: Before uploading the results of that anywhere keep in mind to run "git --bare gc --aggressive" on the resulting folders. [1] http://git.goodpoint.de/?p=overlay-sping.git;a=tree;f=dev-util/svn2git [2] http://www.hartwork.org/public/portage-author-map.txt Created attachment 224801 [details] svn2git rules for portage v2 Updated rules file - one more rule: match /private/genone/gentoo-stats/ repository gentoo-stats branch genone end match Found it using svneverever [1]. Simplified, svneverver creates a tree-view of all non-empty directories that ever existed in the repository. [1] http://git.goodpoint.de/?p=svneverever.git;a=summary Created attachment 224803 [details]
svneverever output on portage history up to r15726
Zac, can you review the rules file against this?
(In reply to comment #43) > Created an attachment (id=224803) [details] > svneverever output on portage history up to r15726 > > Zac, can you review the rules file against this? > That looks perfect to me. Thank you. Just a request: when this is going to happen, can I please be notified in time such that I can do the last merges from trunk to branches/prefix? I think that makes it easier (for me) to start merging the Git way after the conversion. Thanks in advance. (In reply to comment #45) > Just a request: when this is going to happen, can I please be notified in time > such that I can do the last merges from trunk to branches/prefix? I think by now we all agree better support for conversions of svn:ignore information alone is not worth the wait. So there's not much else left to wait for. Speaking for me if you need to do merges please start asap and keep us up to date about the progress. Okay? > I think that > makes it easier (for me) to start merging the Git way after the conversion. > Thanks in advance. Do you use tools besides plain CVS to do that? (If not there are chances merging will be easier with Git.) My comment only applied to Portage SVN, or am I on the wrong bug now? I just want to avoid having to merge with Git a couple of SVN revisions, that's all in this case. Currently, I'm fully up to date with trunk. Every time a new commit to trunk is being made, I have to catch up, which usually is a low effort job. If you guys decide to migrate it *now* (r15841), then that's fine with me. Created attachment 224937 [details] svn2git rules for portage v3 (without gentoo-stats) (In reply to comment #47) > My comment only applied to Portage SVN, or am I on the wrong bug now? Just portage, right here. I have run into a smaller issue with svn2git/svn now that deserves mention but shouldn't stop us: Somehow a part of what's going into gentoo-stats is causing svn2git to abort at revision 2402: Exporting revision 3402 ..Failed to write to process: Error writing to process 67 modifications to "gentoo-stats"Aborted I tried with subversion 1.6.6 and 1.6.9 - same problem. As a workaround I have split the rules file into two halves: - one ripping everything but gentoo-stats (attached right here) - the other gentoo-stats only With that split we get out everything else without errors. As the SVN repo will stick around in read-only mode we can still get gentoo-stats out later without a need to block ourselves with that. On another note while git-svn expects author files of format nick = first last <mail> svn2git expects nick first last <mail> without "=" in what they call "identity map". Failing to notice that results in names starting with "= "... Next steps ========== Unless anybody detects problems with http://git.goodpoint.de/?p=portage.git;a=summary (r1..r15841) I would offer to re-do that (for HEAD, i.e. r15842 or later) when the SVN repo is frozen and push it to git.overlays.gentoo.org. Robin, Zac: please agree on a freeze time and give me green. Push access seems to be usuful to: zmedico grobian volkmar arfrever Created attachment 224945 [details] svn2git rules for portage v3 (gentoo-stats only) For the record ============== - SVN is now frozen, latest revision is 15844 - Portage Git repo is up at http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=summary - Commot access as of the moment: zmedico, grobian, volkmar, arfrever, sping, vapier Next steps ========== - Portage website needs updating to reflect the move: http://www.gentoo.org/proj/en/portage/ - A short mail with commit/branching policies (updated to Git) needs to be sent out to all committers - A post on Planet Gentoo would be cool (In reply to comment #49) > Next steps > ========== > - Portage website needs updating to reflect the move: > http://www.gentoo.org/proj/en/portage/ > - A short mail with commit/branching policies (updated to Git) > needs to be sent out to all committers > - A post on Planet Gentoo would be cool Why git.overlays.g.o?? How about moving it to git.gentoo.org? > Why git.overlays.g.o?? How about moving it to git.gentoo.org?
We have other non-overlay stuff up there. I'm not strongly objecting a move but I think it fits well enough.
Because git.overlays allows non-developers at this time, and that was requested in IRC at one point. If the gitolite changes go successfully, this restriction may change, as it could ease a lot of the ACL needs for gentoo-x86 to use gitolite as well. (In reply to comment #52) > Because git.overlays allows non-developers at this time, and that was requested > in IRC at one point. I'm all for leaving that possibility open: people working on Chromium OS may need commit access at some point, for instance. Zac: please confirm it's the right place so I can re-enable pushing to the repository. Besides me robbat2 and anybody in the overlays team has permissions to do such a change, when you request it. (In reply to comment #53) > Zac: please confirm it's the right place so I can re-enable pushing to the > repository. Besides me robbat2 and anybody in the overlays team has > permissions to do such a change, when you request it. git.overlays sounds good to me. Let's go ahead and enable it. Thank you! You're welcome! Pushing re-enabled. Are commit mail hooks setup for the new git repo? Commit feeds do not work for you? http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=atom PS: I'll get to your mail, I just need more time. (In reply to comment #57) > Commit feeds do not work for you? > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=atom No, because it only lists commits for the master branch, and there is no diff included with them. (In reply to comment #48) > On another note while git-svn expects author files of format > > nick = first last <mail> > > svn2git expects > > nick first last <mail> > > without "=" in what they call "identity map". Failing to notice that results > in names starting with "= "... By now svn2git support git-svn author files, too: http://gitorious.org/svn2git/svn2git/commit/352ad0f90f7d73bec0f36410128cafde183f39ba Please upgrade to =dev-vcs/svn2git-0_pre20100327 if you need that for something. name: gentoo-syntax type: b, convert existing svn repo to git access: world readable, writable by darkside and spatz Thanks. (In reply to comment #60) > name: gentoo-syntax > type: b, convert existing svn repo to git > access: world readable, writable by darkside and spatz Actually, the gentoo-syntax repo on svn.g.o contains eselect-syntax, gentoo-syntax and and empty portage-syntax, each with tags and trunk (no branches). It would be best to create two git repos, one for eselect-syntax and one for gentoo-syntax, both with same access. Created attachment 227057 [details]
svn2git ruleset for converting the gentoo-syntax repo to 2 git repos, {gentoo,eselect}-syntax
Created attachment 227059 [details]
svn2git ruleset for converting the gentoo-syntax repo to 2 git repos, {gentoo,eselect}-syntax
Fixed mistake in /tags/ rule spotted by sping.
Created attachment 227173 [details]
authors-map for gentoo-syntax
I think we don't need this bug any longer. Reopen if I'm wrong there. |