[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] cvs, servers and stuff.

Hello again,

I was thinking that you might want to try something if you get a second machine up.

>From the man page of git-cvsimport:
"Imports a CVS repository into git. It will either create a new repository, or incrementally import into an existing one."

So you might want to try using a "git mirror" of what you guys actually have on CVS. Now personally, I think moving to git alltogether is much better then this "follow the cvs server" sort of thing. There are just a couple of things that are really cool about git (and any distributed scm) versus cvs or svn. 

For those of you who know git well enough, sorry for writing this stuff, but I imagine there's an equal number of devs who don't so I just wanted to give people an idea on what it's about.

1) Local commits. You clone a remote repository (you get the history and everything) and you can then commit to your own local copy of the repository. 

Not only that but you can do just about everything you would do with cvs locally without even needing access to the server. Then when you're done you can merge your superfanstasticincredible feature with the main repository.

2) Local tags and branches. Well, it's part of what I said above but it should get some special notice. You get to branch from what you just cloned and so on ...

3) It's easy to setup. Basically you don't need to set it up at all. You just copy the .git/ directory from your repository to a server in something like http://e.org/e.git and you're all done. Then anyone can mirror it very easily.

4) The repository is well compacted with git-repack. For example, the part of the repository I had was 135MB in size (e17 without the history). With git-repack it all shrunk down to 52MB. Thanks for pointing that out, I wasn't aware of it.

5) The server seems to handle the load quite well, even though downloads may be a tad slower. Ultimately, the compression might turn out to make retrieving faster, and it is probably 

Now I know those so called benchmarks of mine don't indicate these but I have strong doubts about the conditions in which they are run. I believe git to be much faster then cvs if properly set up. And I've seen first hand that it doesn't beat the server to death on 20 simultaneous checkouts.

6) It can be mirrored and offered for retrieval in a variety of methods. There's git:// rsync:// and http:// and it can probably be setup with other webservers like lighttpd (though my attempts to use lighttpd with a git repo misteriously failed).

7) A larger emphasys on branching may actually be good. You might eventually want to create a more stable branch, or you might want to try to rewrite some library in the EFL, in a new cooler way or whatever.

Ultimately that's my best argument for it. With git you can do stuff like that in a more natural way and I generally found that it offers an almost unlimited degree of freedom. 

I tend to believe it's more efficient but I can't really back my claim up with consistent numbers. I have provided a way to test it but my hardware isn't cut out for that. I'm still waiting for someone else's benchmark...

But finally, the best way to test would be to use that second machine as a git mirror and see how well it behaves. You might even go as far as denying anoncvs for a while and telling people to use git for anonymous access instead. 

Well, anyway, you guys know better then I do. If you decide to keep on using CVS, I could make some sort of script to do CVS updates and make dist stuff on an event (like upon email notification or whatever), but it would have to be in Ruby. I can do that if you want to use SVN or Git as well. Your call.