Bugzilla – Full Text Bug Listing
| Summary: | Move to git | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Markus Kuppe <bugs.eclipse.org> |
| Component: | ecf.releng | Assignee: | Markus Kuppe <bugs.eclipse.org> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | denis.roy, nobody, remy.suen, samolisov, sebastian.schmidt2, slewis, wim.jongman |
| Version: | unspecified | ||
| Target Milestone: | 3.4.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 321556, 327759, 327760, 327768 | ||
| Bug Blocks: | |||
|
Description
Markus Kuppe
Thinking about it, does it make sense to aggregate all runtime projects (RT) under a common top-level folder like /gitroot/rt/${project} ?
> Thinking about it, does it make sense to aggregate all runtime projects (RT)
> under a common top-level folder like /gitroot/rt/${project} ?
We've been removing references to top-level project names since it a) shortens URIs and b) facilitates project moves from one top-level to another. So far Git repos operate without the notion of a top-level project and that is my personal preference, but the RT PMC may with to group all its projects under a common contain. Talk to your PMC and let me know what the outcome is.
(In reply to comment #2) > We've been removing references to top-level project names since it a) shortens > URIs and b) facilitates project moves from one top-level to another. So far > Git repos operate without the notion of a top-level project and that is my > personal preference, but the RT PMC may with to group all its projects under a > common contain. Talk to your PMC and let me know what the outcome is. Makes sense to me too. At some point however, we might need a more organized page for http://git.eclipse.org/c/ when the number of projects reaches a certain point. Absolutely, and I've been thinking about that for a while now. My first thought is to simply insert a break to separate the projects alphabetically. bpmn2 bpmnmodeler ---- emf/org.eclipse.emf.mwe.git emf/org.eclipse.emf.mwe.releng.git ---- gemini.web/org.eclipse.gemini.web.gemini-web-container.git (etc). But we can use another bug to track that effort. Do you have an estimate when ECF will be moved to git? Sorry, I guess I got distracted by the sub-issues. I've created /gitroot/ecf, so feel free to migrate as you'd like, in accordance with our Migration Guide [1]. I would appreciate Scott's +1 on this bug, however. [1] http://wiki.eclipse.org/Git/Migrating_to_Git (In reply to comment #6) > I would appreciate Scott's +1 on this bug, however. Here's a pointer to the public discussion we held on ecf-dev [0] Markus [0] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg03855.html Sounds like fun! Two more questions... - Is is possible to keep a continuously synced ro CVS repo after moving to git? - Which tool is used to sync CVS to git and at what time is the sync done? (In reply to comment #6) > Sorry, I guess I got distracted by the sub-issues. I've created /gitroot/ecf, > so feel free to migrate as you'd like, in accordance with our Migration Guide > [1]. I would appreciate Scott's +1 on this bug, however. +1 > - Is is possible to keep a continuously synced ro CVS repo after moving to git? It may be possible, but we don't support that. We can keep the 'old' CVS repo around, read-only. > - Which tool is used to sync CVS to git and at what time is the sync done? For our CVS->Git mirrors we use git-cvsimport, and our Git sync begins at 13:12 Eastern time every day. Depending on server load and how many changes, it can take a few hours to crawl all the projects. ECF 3.4 (fall release) will be released from git Webmaster have created the /gitroot/ecf folder, thanks! Changing assignee to myself as the remainder of the work is up to us. (In reply to comment #11) > > - Which tool is used to sync CVS to git and at what time is the sync done? > > For our CVS->Git mirrors we use git-cvsimport, and our Git sync begins at 13:12 > Eastern time every day. Depending on server load and how many changes, it can > take a few hours to crawl all the projects. Denis, do you have a tool that does a consistency check between CVS and git after an import with git-cvsimport? I don't have a tool to do that. (In reply to comment #15) > I don't have a tool to do that. How long do need notice in advance to set CVS to read-only? I'm not sure I understand that question. How much advance do _we_ need? We can do this anytime. (In reply to comment #17) > I'm not sure I understand that question. How much advance do _we_ need? We > can do this anytime. That's exactly the question. Can you do it on short notice? Denis, as per http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg04345.html please set ECF's CVS to read-only. Thanks (In reply to comment #19) > Denis, as per http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg04345.html please > set ECF's CVS to read-only. Thanks Done. For completeness, I've set the entire tree of /cvsroot/rt/org.eclipse.ecf to read-only. I forgot to set the group ID execution bit on the repo and thus a commit, the screwed up the repo permissions.. Unfortunately we cannot fix this ourself. Denis, please fix the permissions of /gitroot/ecf/org.eclipse.ecf.git In the meantime a push might either be rejected or succeed. Depending with object/ folder is accessed. (In reply to comment #21) > I forgot to set the group ID execution bit on the repo and thus a commit, the > screwed up the repo permissions.. Unfortunately we cannot fix this ourself. > > Denis, please fix the permissions of /gitroot/ecf/org.eclipse.ecf.git > > In the meantime a push might either be rejected or succeed. Depending with > object/ folder is accessed. Rereported on bug #327768 > Denis, please fix the permissions of /gitroot/ecf/org.eclipse.ecf.git Done. I've also set the sharedrepository = 1 in your config file. This will preserve group writable permissions. > Rereported on bug #327768 But why? Have been using git for a while now, thanks everybody for the help. :-) |