Hi,
For a while now, I've been maintaining a git conversion of the Fedora CVS tree, pulling in a copy of the CVS tree via rsync, and running some local scripts to convert that to git, incrementally updating the git tree as commits are made to the CVS tree.
(For more background info, see here:)
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00561.htm...
I think most of the issues with the conversion have been worked out, and I'd like to make this available to the World in some way. I was wondering whether it makes sense to host something like this on Fedora infrastructure.
Note that this is _not_ a proposal to replace CVS by git.
The git tree is currently a read-only (slave) version of the CVS tree, and I expect it to stay that way for some time. But even though Fedora isn't switching VCSes at this point, I think it would still make sense to have git/hg/random-other-VCS conversions of the Fedora CVS tree publically available, for a number of reasons: - Give package maintainers the option of working with their favorite VCS for local development (while continuing to use CVS when committing things upstream.) - All the advantages of other version control systems over CVS, e.g.: - Give people the opportunity to pull a local copy of the entire tree or parts of the tree for local browsing of packages and their history without having to go through the server (CVS doesn't support this, although you _could_ just rsync the entire CVS tree to your local machine...) - Allow stacking commits, reverting commits, merging commits, splitting commits, reordering commits, etc., before the changes are pushed into the CVS tree and become final. - Allow easy maintaining of local branches of packages.
What would be needed to host this on Fedora infrastructure: - Some disk space. The size of the converted git tree is about 725 megabytes after packing, but for experimenting it would be good to have a bit more space available, say, 10G or so. - Open ports. For browsing the git tree via the web, port 80 access would be needed, and for allowing people to clone the tree over git://, port 9418 access would be useful. - Read-only access to the ,v files in the CVS tree, say, over NFS.
Ideas?
thanks, Lennert
On Mon, 2007-11-19 at 12:01 +0100, Lennert Buytenhek wrote:
The git tree is currently a read-only (slave) version of the CVS tree, and I expect it to stay that way for some time. But even though Fedora isn't switching VCSes at this point, I think it would still make sense to have git/hg/random-other-VCS conversions of the Fedora CVS tree publically available ...
+1 to the general idea.
Are you interested in building and maintaining the solution in Fedora Infrastructure? Just asking as a bystander ... :)
- Karsten
Karsten Wade wrote:
On Mon, 2007-11-19 at 12:01 +0100, Lennert Buytenhek wrote:
The git tree is currently a read-only (slave) version of the CVS tree, and I expect it to stay that way for some time. But even though Fedora isn't switching VCSes at this point, I think it would still make sense to have git/hg/random-other-VCS conversions of the Fedora CVS tree publically available ...
+1 to the general idea.
Are you interested in building and maintaining the solution in Fedora Infrastructure? Just asking as a bystander ... :)
What problem are we trying to solve by doing this or what added functionality will we get that people can't get by just downloading a snapshot and importing it into git themselves?
-Mike
On Tue, 2007-11-20 at 08:39 -0600, Mike McGrath wrote:
Karsten Wade wrote:
On Mon, 2007-11-19 at 12:01 +0100, Lennert Buytenhek wrote:
The git tree is currently a read-only (slave) version of the CVS tree, and I expect it to stay that way for some time. But even though Fedora isn't switching VCSes at this point, I think it would still make sense to have git/hg/random-other-VCS conversions of the Fedora CVS tree publically available ...
+1 to the general idea.
Are you interested in building and maintaining the solution in Fedora Infrastructure? Just asking as a bystander ... :)
What problem are we trying to solve by doing this or what added functionality will we get that people can't get by just downloading a snapshot and importing it into git themselves?
Downloading a snapshot of what? The entire repo? Do we have that actually available? Even if so, it's still not an incremental grab.
Not that I'm fully sold on mirroring our pkgcvs data across multiple SCMs, both from a disk space and a maintenance perspective.
Jeremy
Jeremy Katz wrote:
On Tue, 2007-11-20 at 08:39 -0600, Mike McGrath wrote:
Karsten Wade wrote:
On Mon, 2007-11-19 at 12:01 +0100, Lennert Buytenhek wrote:
The git tree is currently a read-only (slave) version of the CVS tree, and I expect it to stay that way for some time. But even though Fedora isn't switching VCSes at this point, I think it would still make sense to have git/hg/random-other-VCS conversions of the Fedora CVS tree publically available ...
+1 to the general idea.
Are you interested in building and maintaining the solution in Fedora Infrastructure? Just asking as a bystander ... :)
What problem are we trying to solve by doing this or what added functionality will we get that people can't get by just downloading a snapshot and importing it into git themselves?
Downloading a snapshot of what? The entire repo? Do we have that actually available? Even if so, it's still not an incremental grab.
I think the closest is webfiles:
http://cvs.fedoraproject.org/webfiles/
-Mike
On Tue, Nov 20, 2007 at 08:39:20AM -0600, Mike McGrath wrote:
The git tree is currently a read-only (slave) version of the CVS tree, and I expect it to stay that way for some time. But even though Fedora isn't switching VCSes at this point, I think it would still make sense to have git/hg/random-other-VCS conversions of the Fedora CVS tree publically available ...
+1 to the general idea.
Are you interested in building and maintaining the solution in Fedora Infrastructure? Just asking as a bystander ... :)
What problem are we trying to solve by doing this or what added functionality will we get that people can't get by just downloading a snapshot and importing it into git themselves?
As far as I can see, the wegfiles snapshots are CVS checkouts, and don't contain history information. As such, you don't get the ability to view history locally, or to easily work with multiple branches, or some of the other things I described here:
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00561.htm...
(If you wanted to perform the conversion with history on your local machine, you'd have to rsync the entire Fedora CVS tree, weighing in at about 250k files.)
On 11/20/07, Mike McGrath mmcgrath@redhat.com wrote:
Karsten Wade wrote:
On Mon, 2007-11-19 at 12:01 +0100, Lennert Buytenhek wrote:
The git tree is currently a read-only (slave) version of the CVS tree, and I expect it to stay that way for some time. But even though Fedora isn't switching VCSes at this point, I think it would still make sense to have git/hg/random-other-VCS conversions of the Fedora CVS tree publically available ...
+1 to the general idea.
Are you interested in building and maintaining the solution in Fedora Infrastructure? Just asking as a bystander ... :)
What problem are we trying to solve by doing this
I see it as a POC for a future VCS alternative. Now that Koji is getting some support for building from a VCS other than CVS I we are getting to the point where people can actually try something other than CVS for maintaining packages, rather than just talk about it.
or what added functionality will we get that people can't get by just downloading a snapshot and importing it into git themselves?
The structure and the size of the package CVS makes it difficult for someone to casually make their own git mirror.
Jeff
On Tue, Nov 20, 2007 at 12:25:09AM -0800, Karsten Wade wrote:
The git tree is currently a read-only (slave) version of the CVS tree, and I expect it to stay that way for some time. But even though Fedora isn't switching VCSes at this point, I think it would still make sense to have git/hg/random-other-VCS conversions of the Fedora CVS tree publically available ...
+1 to the general idea.
Are you interested in building and maintaining the solution in Fedora Infrastructure? Just asking as a bystander ... :)
Yep.
Lennert Buytenhek buytenh@wantstofly.org wrote:
For a while now, I've been maintaining a git conversion of the Fedora CVS tree, pulling in a copy of the CVS tree via rsync, and running some local scripts to convert that to git, incrementally updating the git tree as commits are made to the CVS tree.
(For more background info, see here:)
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00561.htm...
Nice!
Maintaining an accurate cvs->git mirror is not trivial (I know, from experience with the full repositories of coreutils, emacs, libc, and a few more). If you can do it well and keep it accurate, then it'd make a fine and very welcome service.
I've found that the initial conversion works best with cvsparse. It's _much_ more efficient than git-cvsimport, and more reliable, too.
Jim Meyering jim@meyering.net wrote: ...
Maintaining an accurate cvs->git mirror is not trivial (I know, from experience with the full repositories of coreutils, emacs, libc, and a few more). If you can do it well and keep it accurate, then it'd make a fine and very welcome service.
I've found that the initial conversion works best with cvsparse.
s/cvsparse/parsecvs/
FYI, sources here
git-clone git://people.freedesktop.org/~keithp/parsecvs
It's _much_ more efficient than git-cvsimport, and more reliable, too.
On Tue, Nov 20, 2007 at 05:01:40PM +0100, Jim Meyering wrote:
Maintaining an accurate cvs->git mirror is not trivial (I know, from experience with the full repositories of coreutils, emacs, libc, and a few more). If you can do it well and keep it accurate, then it'd make a fine and very welcome service.
I've found that the initial conversion works best with cvsparse.
s/cvsparse/parsecvs/
That's what I've been using.
On Mon, Nov 19, 2007 at 12:01:21PM +0100, Lennert Buytenhek wrote:
I think most of the issues with the conversion have been worked out, and I'd like to make this available to the World in some way. I was wondering whether it makes sense to host something like this on Fedora infrastructure.
There seemed to be a couple of folks against this, and a couple in favor, but no decision either way.
Anyone else have opinions/ideas about this?
Lennert Buytenhek wrote:
Hi,
For a while now, I've been maintaining a git conversion of the Fedora CVS tree, pulling in a copy of the CVS tree via rsync, and running some local scripts to convert that to git, incrementally updating the git tree as commits are made to the CVS tree.
(For more background info, see here:)
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00561.htm...
I think most of the issues with the conversion have been worked out, and I'd like to make this available to the World in some way. I was wondering whether it makes sense to host something like this on Fedora infrastructure.
Note that this is _not_ a proposal to replace CVS by git.
The git tree is currently a read-only (slave) version of the CVS tree, and I expect it to stay that way for some time. But even though Fedora isn't switching VCSes at this point, I think it would still make sense to have git/hg/random-other-VCS conversions of the Fedora CVS tree publically available, for a number of reasons:
- Give package maintainers the option of working with their favorite VCS for local development (while continuing to use CVS when committing things upstream.)
- All the advantages of other version control systems over CVS, e.g.:
- Give people the opportunity to pull a local copy of the entire tree or parts of the tree for local browsing of packages and their history without having to go through the server (CVS doesn't support this, although you _could_ just rsync the entire CVS tree to your local machine...)
- Allow stacking commits, reverting commits, merging commits, splitting commits, reordering commits, etc., before the changes are pushed into the CVS tree and become final.
- Allow easy maintaining of local branches of packages.
What would be needed to host this on Fedora infrastructure:
- Some disk space. The size of the converted git tree is about 725 megabytes after packing, but for experimenting it would be good to have a bit more space available, say, 10G or so.
- Open ports. For browsing the git tree via the web, port 80 access would be needed, and for allowing people to clone the tree over git://, port 9418 access would be useful.
- Read-only access to the ,v files in the CVS tree, say, over NFS.
Ideas?
This sounds like something we could do, but I don't think we should do it. For one, after we move the hosted stuff away from cvs-int, that box will get a complete makover and one that, as far as I can tell, won't include git. I'm not sure what problem this solves really.
If there is a real need in Fedora to use git, why not just put together a proposal for migrating cvs to git? Lots of people have tried this, its not an easy task. But adding an additional SCM for GIT which is JUST a copy of what's in CVS sounds like a waste of our resources. Why not also do SVN, BZR and Mercurial?
-Mike
Mike McGrath mmcgrath@redhat.com wrote:
This sounds like something we could do, but I don't think we should do it. For one, after we move the hosted stuff away from cvs-int, that box will get a complete makover and one that, as far as I can tell, won't include git. I'm not sure what problem this solves really.
If there is a real need in Fedora to use git, why not just put together a proposal for migrating cvs to git? Lots of people have
Hi Mike,
That's a much bigger shift, and will probably take a long time to realize. On the other hand, providing a service like this is easy, and might help nay-sayers realize the value. In the mean time, people who find it useful get the benefit right away.
tried this, its not an easy task. But adding an additional SCM for GIT which is JUST a copy of what's in CVS sounds like a waste of our resources. Why not also do SVN, BZR and Mercurial?
IMHO, they're not as useful.
If Fedora doesn't want to do this, I can probably set up something independent and provide public git:// access.
Jim Meyering wrote:
Mike McGrath mmcgrath@redhat.com wrote:
tried this, its not an easy task. But adding an additional SCM for GIT which is JUST a copy of what's in CVS sounds like a waste of our resources. Why not also do SVN, BZR and Mercurial?
IMHO, they're not as useful.
And thats the real trick, I'd imagine the mercurial, svn and bzr guys would disagree with you.
If Fedora doesn't want to do this, I can probably set up something independent and provide public git:// access.
If someone else wants to host it I'm all for it, we can certainly make it easier to get at the raw CVS repo. If the other officers disagree please let it be known, but this sounds more like a distraction/one off then something that adds value to our infrastructure.
-Mike
On Tue, 2007-11-27 at 13:39 -0600, Mike McGrath wrote:
Jim Meyering wrote:
Mike McGrath mmcgrath@redhat.com wrote:
tried this, its not an easy task. But adding an additional SCM for GIT which is JUST a copy of what's in CVS sounds like a waste of our resources. Why not also do SVN, BZR and Mercurial?
IMHO, they're not as useful.
And thats the real trick, I'd imagine the mercurial, svn and bzr guys would disagree with you.
If Fedora doesn't want to do this, I can probably set up something independent and provide public git:// access.
If someone else wants to host it I'm all for it, we can certainly make it easier to get at the raw CVS repo. If the other officers disagree please let it be known, but this sounds more like a distraction/one off then something that adds value to our infrastructure.
I concur.
-sv
Mike McGrath mmcgrath@redhat.com wrote:
Jim Meyering wrote:
Mike McGrath mmcgrath@redhat.com wrote:
tried this, its not an easy task. But adding an additional SCM for GIT which is JUST a copy of what's in CVS sounds like a waste of our resources. Why not also do SVN, BZR and Mercurial?
IMHO, they're not as useful.
And thats the real trick, I'd imagine the mercurial, svn and bzr guys would disagree with you.
If Fedora doesn't want to do this, I can probably set up something independent and provide public git:// access.
If someone else wants to host it I'm all for it, we can certainly make it easier to get at the raw CVS repo. If the other officers disagree please let it be known, but this sounds more like a distraction/one off then something that adds value to our infrastructure.
At 5GB+, (4.5GB for a copy of the cvs repo + 700MB for git) that's too heavy for me. And besides, it'd really be better under the Fedora umbrella. Seeing as how much more efficient the git protocol is, if a few people switch to it from cvs, it'd actually decrease network bandwidth requirements.
Is there anything I can do to revive this idea? For example, I'd be happy to own and set up the tools/infrastructure required to make it all work (I've already done this on three public servers). All I'd need is an open git port and access to the config files.
Jim
On Thu, 2007-11-29 at 17:25 +0100, Jim Meyering wrote:
At 5GB+, (4.5GB for a copy of the cvs repo + 700MB for git) that's too heavy for me. And besides, it'd really be better under the Fedora umbrella. Seeing as how much more efficient the git protocol is, if a few people switch to it from cvs, it'd actually decrease network bandwidth requirements.
The problem is we're not running out of network bandwidth most of the time. We're running out of disk space. Pretty badly, too.
-sv
seth vidal skvidal@fedoraproject.org wrote:
On Thu, 2007-11-29 at 17:25 +0100, Jim Meyering wrote:
At 5GB+, (4.5GB for a copy of the cvs repo + 700MB for git) that's too heavy for me. And besides, it'd really be better under the Fedora umbrella. Seeing as how much more efficient the git protocol is, if a few people switch to it from cvs, it'd actually decrease network bandwidth requirements.
The problem is we're not running out of network bandwidth most of the time. We're running out of disk space. Pretty badly, too.
One big advantage to switching from CVS to git is the savings in disk space. With the example above it's pretty obvious: you can save exactly the same information using git in 1/6 to 1/4th the space.
Jim Meyering wrote:
seth vidal skvidal@fedoraproject.org wrote:
On Thu, 2007-11-29 at 17:25 +0100, Jim Meyering wrote:
At 5GB+, (4.5GB for a copy of the cvs repo + 700MB for git) that's too heavy for me. And besides, it'd really be better under the Fedora umbrella. Seeing as how much more efficient the git protocol is, if a few people switch to it from cvs, it'd actually decrease network bandwidth requirements.
The problem is we're not running out of network bandwidth most of the time. We're running out of disk space. Pretty badly, too.
One big advantage to switching from CVS to git is the savings in disk space. With the example above it's pretty obvious: you can save exactly the same information using git in 1/6 to 1/4th the space.
Clearly you have tenacity and a desire to see change. If I were you I'd join the SCMSig:
http://fedoraproject.org/wiki/Infrastructure/SCMSig (some of us still hang out in #fedora-scm)
Schedule and request a meeting, host that meeting and have your voice be heard. I, for one, would attend whatever meeting you schedule and many others in the sig would as well. Take a deep breath, send the email and dive right in. (I'm being totally serious here, I'll be disappointed if I don't get a meeting request soon :-P
-Mike
Jim Meyering wrote:
Mike McGrath mmcgrath@redhat.com wrote:
Jim Meyering wrote:
Mike McGrath mmcgrath@redhat.com wrote:
tried this, its not an easy task. But adding an additional SCM for GIT which is JUST a copy of what's in CVS sounds like a waste of our resources. Why not also do SVN, BZR and Mercurial?
IMHO, they're not as useful.
And thats the real trick, I'd imagine the mercurial, svn and bzr guys would disagree with you.
If Fedora doesn't want to do this, I can probably set up something independent and provide public git:// access.
If someone else wants to host it I'm all for it, we can certainly make it easier to get at the raw CVS repo. If the other officers disagree please let it be known, but this sounds more like a distraction/one off then something that adds value to our infrastructure.
At 5GB+, (4.5GB for a copy of the cvs repo + 700MB for git) that's too heavy for me. And besides, it'd really be better under the Fedora umbrella. Seeing as how much more efficient the git protocol is, if a few people switch to it from cvs, it'd actually decrease network bandwidth requirements.
Is there anything I can do to revive this idea? For example, I'd be happy to own and set up the tools/infrastructure required to make it all work (I've already done this on three public servers). All I'd need is an open git port and access to the config files.
If you think git is so much better than CVS (many would agree with you) come up with a proposal on how we can migrate to it, propose it, then convince people its the right thing to do.
-Mike
Mike McGrath mmcgrath@redhat.com wrote:
Jim Meyering wrote:
...
At 5GB+, (4.5GB for a copy of the cvs repo + 700MB for git) that's too heavy for me. And besides, it'd really be better under the Fedora umbrella. Seeing as how much more efficient the git protocol is, if a few people switch to it from cvs, it'd actually decrease network bandwidth requirements.
Is there anything I can do to revive this idea? For example, I'd be happy to own and set up the tools/infrastructure required to make it all work (I've already done this on three public servers). All I'd need is an open git port and access to the config files.
If you think git is so much better than CVS (many would agree with you) come up with a proposal on how we can migrate to it, propose it, then convince people its the right thing to do.
I consider the automated cvs-to-git mirroring to be the first step in any conversion proposal:
First, give people an idea of what they can expect in a git-based dVCS, without requiring any change. It lets people continue to use the tools they're familiar with, and allows the better parts of a dVCS to begin to show up the radar of those who haven't yet had time to explore them. It also begins to highlight the parts (if any) of the existing process that might end up being adjusted with a dVCS. For example, in CVS, there's no reason to put a summary on the first line of the commit log message. But with any dVCS, it's encouraged. This shows up when you compare views of commit summaries in pure-dVCS projects and those where people have not yet adopted the first-line-is-summary standard.
Helping a big project transition is a big job, so IMHO, the only way to do it is incrementally. If you try to come up with an all-encompassing proposal, you might never get buy-in from enough people and you'll wait forever. With something like this, a dVCS gets a foot in the door. And if/when people conclude it's worthless or want to try another, it's easy to revert or shift gears.
Here's a feature of git that'd be handy if there ever is a cut-over: one can set up a read-only[1] cvs-pserver mirror to the master git repository. Then, while commits/pushes all go directly through git, people can still use their cvs clients for read-only operations on the very same git repository. Offering that service helped to convert a few projects on savannah.gnu.org from CVS to git: automake, autoconf, m4. The git-cvsserver emulation is 'ok', but for example doesn't handle the "-D date-string" part of the protocol. Not a big deal, of course.
[1] you can even use git-cvsserver emulation to *write* into the git repository, but I don't think it's mature enough for that.
Jim Meyering wrote:
Mike McGrath mmcgrath@redhat.com wrote:
Jim Meyering wrote:
...
At 5GB+, (4.5GB for a copy of the cvs repo + 700MB for git) that's too heavy for me. And besides, it'd really be better under the Fedora umbrella. Seeing as how much more efficient the git protocol is, if a few people switch to it from cvs, it'd actually decrease network bandwidth requirements.
Is there anything I can do to revive this idea? For example, I'd be happy to own and set up the tools/infrastructure required to make it all work (I've already done this on three public servers). All I'd need is an open git port and access to the config files.
If you think git is so much better than CVS (many would agree with you) come up with a proposal on how we can migrate to it, propose it, then convince people its the right thing to do.
I consider the automated cvs-to-git mirroring to be the first step in any conversion proposal:
First, give people an idea of what they can expect in a git-based dVCS, without requiring any change. It lets people continue to use the tools they're familiar with, and allows the better parts of a dVCS to begin to show up the radar of those who haven't yet had time to explore them.
I don't really buy this because it's a one-way transaction. The people that need to be convinced that there's value in switching to git vs bzr vs hg vs svn also have commit rights to the main repository. For a demo to reach this audience you need to get them the ability to work from this tree. Which means they need to be able to checkout, checkin, tag, and request builds from it.
[snip]
Helping a big project transition is a big job, so IMHO, the only way to do it is incrementally. If you try to come up with an all-encompassing proposal, you might never get buy-in from enough people and you'll wait forever.
I'm in agreement with this part. From trying to work up a trial before I have to say that the hardest part is figuring out how we can implement changes incrementally *and* non-disruptively. (Note that the changeover will be disruptive. But we want to make it a one-time event, not an on-going, this time we're switching to bzr, next time we're switching to exploded trees, etc.)
However, I don't see a read-only mirror as an incremental step towards moving to a new VCS. It's more of a value-add for downstream distributions. IMHO we'd be much better figuring out a real interim step to make it possible for package maintainers to do actual work within a new VCS.
-Toshio
Toshio Kuratomi a.badger@gmail.com wrote:
Jim Meyering wrote:
...
I consider the automated cvs-to-git mirroring to be the first step in any conversion proposal:
First, give people an idea of what they can expect in a git-based dVCS, without requiring any change. It lets people continue to use the tools they're familiar with, and allows the better parts of a dVCS to begin to show up the radar of those who haven't yet had time to explore them.
I don't really buy this because it's a one-way transaction. The people that need to be convinced that there's value in switching to git vs bzr vs hg vs svn also have commit rights to the main repository. For a demo to reach this audience you need to get them the ability to work from this tree. Which means they need to be able to checkout, checkin, tag, and request builds from it.
Hi Toshio,
[didn't we talk at a Mexican place after the fudcon in Boston?]
Using such a mirror need not be a one-way transaction. Obviously, it'd be far less useful if there were such a limitation.
When I do serious work against an upstream CVS repository, I arrange to mirror the CVS repo to git, and do all of my work in git, committing changes on private git branches. Then, I can easily rebase each of those branches (sort of like cvs update), to synchronize with newer upstream changes on the parent branch.[*] When I want to commit to cvs, it's easy to automate using git-cvsexportcommit. While this MO is not as comfortable as working in a git-only environment, it does help give you a feel for what it'd be like, and *I* certainly appreciate it. Of course, this can't help for tag/release-related operations, but it's a good start for the rest.
Even with this slightly-contorted routine, I've appreciated using git: for example, while using conventional diff, patch, and cvs, it's easy to forget to "cvs add" a new file that was added by a patch. It's also easy to forget to apply "chmod a+x..." to a script just added by a patch. But in git, that doesn't happen as much, because the tools do more of the work for you. And git-cvsexportcommit takes care of the details of making sure everything in a git change set makes it back into a cvs "commit".
Jim
[*] In case you haven't seen it yet, "git rebase --interactive" is very useful, if you care about the "perfect patch" sort of process. With it, there's no need for quilt/stgit/etc.
Jim Meyering wrote:
Toshio Kuratomi a.badger@gmail.com wrote:
Jim Meyering wrote:
...
I consider the automated cvs-to-git mirroring to be the first step in any conversion proposal:
First, give people an idea of what they can expect in a git-based dVCS, without requiring any change. It lets people continue to use the tools they're familiar with, and allows the better parts of a dVCS to begin to show up the radar of those who haven't yet had time to explore them.
I don't really buy this because it's a one-way transaction. The people that need to be convinced that there's value in switching to git vs bzr vs hg vs svn also have commit rights to the main repository. For a demo to reach this audience you need to get them the ability to work from this tree. Which means they need to be able to checkout, checkin, tag, and request builds from it.
Hi Toshio,
[didn't we talk at a Mexican place after the fudcon in Boston?]
[Yeah, I think we did :-) ]
Using such a mirror need not be a one-way transaction. Obviously, it'd be far less useful if there were such a limitation.
When I do serious work against an upstream CVS repository, I arrange to mirror the CVS repo to git, and do all of my work in git, committing changes on private git branches. Then, I can easily rebase each of those branches (sort of like cvs update), to synchronize with newer upstream changes on the parent branch.[*] When I want to commit to cvs, it's easy to automate using git-cvsexportcommit. While this MO is not as comfortable as working in a git-only environment, it does help give you a feel for what it'd be like, and *I* certainly appreciate it. Of course, this can't help for tag/release-related operations, but it's a good start for the rest.
That sounds better. Where does all this get setup? On the user's machine or the server? I still don't know if you'll get many developers to try it since you still have to keep both the git and cvs tree so they can make tag and make build. git can't push tags back to cvs?
Even with this slightly-contorted routine, I've appreciated using git: for example, while using conventional diff, patch, and cvs, it's easy to forget to "cvs add" a new file that was added by a patch. It's also easy to forget to apply "chmod a+x..." to a script just added by a patch. But in git, that doesn't happen as much, because the tools do more of the work for you. And git-cvsexportcommit takes care of the details of making sure everything in a git change set makes it back into a cvs "commit".
Git does that when you apply a patch? Or only when you apply a patch that was generated via git? (I tried git apply foo.patch but that didn't seem to have the behaviour you mention.)
-Toshio
Toshio Kuratomi a.badger@gmail.com wrote: ...
When I do serious work against an upstream CVS repository, I arrange to mirror the CVS repo to git, and do all of my work in git, committing changes on private git branches. Then, I can easily rebase each of those branches (sort of like cvs update), to synchronize with newer upstream changes on the parent branch.[*] When I want to commit to cvs, it's easy to automate using git-cvsexportcommit. While this MO is not as comfortable as working in a git-only environment, it does help give you a feel for what it'd be like, and *I* certainly appreciate it. Of course, this can't help for tag/release-related operations, but it's a good start for the rest.
That sounds better. Where does all this get setup? On the user's machine or the server?
The only part that's done on the server is to maintain the git repo in sync with the master CVS repository. For my usage, I keep two checked-out repos for each such project: the cvs one and the git one. I never change anything in the CVS one manually. That's only for the automated commit-from-git-to-cvs process. Other than that, there's almost no set-up required. I use a tiny bash function to encapsulate the details of "apply this git change-set to the corresponding CVS working directory". That just runs git-cvsexportcommit with options that apply the patch and ensure that there was no fuzz. git-cvsexportcommit has an option to perform the commit, but I don't use that -- prefer to verify, first. git-cvsexportcommit's output includes the "cvs commit -F .msg file1 file2 ..." command that'd be required to commit the affected files, using the same message you used in the git commit.
I still don't know if you'll get many developers to try it since you still have to keep both the git and cvs tree so they can make tag and make build.
We won't know until we try, will we? :-)
git can't push tags back to cvs?
That's not part of git-cvsexportcommit's charter. However, the cvs-to-git mirroring operation does preserve tags.
Even with this slightly-contorted routine, I've appreciated using git: for example, while using conventional diff, patch, and cvs, it's easy to forget to "cvs add" a new file that was added by a patch. It's also easy to forget to apply "chmod a+x..." to a script just added by a patch. But in git, that doesn't happen as much, because the tools do more of the work for you. And git-cvsexportcommit takes care of the details of making sure everything in a git change set makes it back into a cvs "commit".
Git does that when you apply a patch?
Yes. In the scenario I described above, it does, since git generates the patch and applies it, too. The format of classical "diff" output does not (and cannot) contain the information required for git tools to perform the extra checks.
Or only when you apply a patch that was generated via git? (I tried git apply foo.patch but that didn't seem to have the behaviour you mention.)
Right. That's an inherent limitation in the standard format.
FYI, once you've committed a change in git, you can get the latest change set in patch format like this:
git-format-patch --stdout --signoff HEAD~1 > patch
or the latest N change sets:
git-format-patch --stdout --signoff HEAD~N > patch
Then, you can later apply that series of change sets via git-am, e.g.
git-am patch
Applying patches that way preserves file permissions, author name and email, dates, etc.
infrastructure@lists.fedoraproject.org