General developer forum

Not having a direct alternative for Tortoise would be a complete pain.

IMO the developers need to think more widely about the current user base and it's ability to cope with another method of updating and the (unnecessary?) disruption that would cause.

As a non-developer here are my questions:

MD and MHQ: Is CVS just so bad it really needs to be abandoned?
ML et al: Is GIT really perfect? No downsides? Please think beyond your own set up on this.

Moz picked Mercurial (Hg) because Windows support was rather weak when they made the call. That is no longer the case - git outpaces hg by a large margin on stability and features on Windows these days.

Yes, that is right. People with shell access to those servers (Catalyst employees) sometimes run the sync manually when that happens.

The sync runs at 5:30am NZ time.

Also it's a bit disturbing that there doesn't seem to be enough of a git community, or that the git community is so hardcore linux-only 'who needs an IDE when you have vi AND front-panel switches', so that progress on the efforts to integrate tools [Cheetah, Eclipse plugin] appears slow. Similarly the UI on the web version appears to be a bit crap.

I definitely do not think the git community is small! Just look at the number of people in the irc channel, activity on the mailing list and number of projects switching to it.

My impression is actually that the pace of development is amazingly fast!

I do agree that I expect there was a shell-based bias with development and that might be why the plugins and gui tools aren't as developed. But I think thats quite natural given the origins and the only way is up.

The complexity of putting some of the real power of git into a gui (rearranging commits, granual hunk commits, rearranging branches ) is also non-trivial.

(And the web ui grows on you - I think the major thing people don't like is the fact it doesn't show the tree by default).

Yes, OU funded the main part of my work (and Martyn Smith's) work on git-cvsserver (*thanks!*), which Linus Torvalds has both recommended, and called "insane".

... about par for the course, I guess...

The git community is growing fast - and notably, it seems to be outpacing all the other DSCMs in userbase, enhancements and dev community. There are quite a few people working on the GUI aspects, AFAICS -- part of the problem is that we need different visual metaphors too. Mimicking TortoiseCVS and the CVS/SVN Eclipse UIs doesn't get us anywhere

(The Eclipse efforts are IMO delayed because the team doing it wants a pure Java implementation of the whole stack. So they are doing both the UI stuff and tracking that fast-moving target that is GIT.)

Edit: Some graphs of reports from Debian follow

- Installation reports - Git growth amongst DSCMs http://tinyurl.com/4uemg2
- Usage reports - With a longer timeframe, and counting CVS/SVN http://tinyurl.com/4hu2cn

Git is actually getting momentum in a range of areas... spurred on in no small way by a particular MVC web framework project's decision to move from SVN to Git.

Some interesting stuff out of that includes:

http://github.com/ - get a free personal public git repo with some cool tools and
http://gitcasts.com/ - free screencasts by Scott Chacon on using Git... admittedly with a particular bias. The most recent (at time of writing) one is: "Git on Windows"

Myles C.

NB. That particular framework project now manages its collaborative development, bug tracking, etc. with http://lighthouseapp.com/ (a tool that includes GitHub integration).

"and the TortoiseCVS lookalike (Cheetah) are evolving quickly"

I hope that is the case, but according to the comments here: http://code.google.com/p/msysgit/wiki/GitCheetah the original developer has dropped Cheetah?

Couple of additional notes --

From my POV as part/instigator of the group of developers using GIT, I think there is no hurry to move the main dev tree to GIT. We could make it a temporary practice that new _feature_ code should be drafted as a nice patch-series in GIT, reviewed there, and then landed in CVS, like I did with my accesslib rework. IMHO, this model leads to higher-quality code - the reviewer can push-back a bit, and force the author of the feature to do cleanups _before_ it gets into CVS HEAD. And if the branch turns out to be a dead end... well, it's as if it had never happened

As a developer, I find that liberating.

And from a 'moodle maintainer' POV, our current CVS HEAD has some dead ends lying there, "disabled". That is dead code that even makes it to releases. So... thankfully moodle is well modularised - users don't get to see it at all. But it would be better to ship clean code - one of these bits of dead code could have security issues

With the approach above, the core team gets 99% of the migration benefits, with 1% of the risk. Dealing with git-cvsexportcommit and the occassional minor drift is a pain, but I think it might be worthwhile.

Another point is that once we do move wholesale to git, we can look into small variations of the "purely centralised, HEAD and _STABLE" approach we have now. For starters, things like the _REVIEWED branch stuff are much easier and cleaner to maintain. And over time, we might find that it makes sense to run more feature branches, and our HEAD branch be an "integration" place.

Back to my real work - I'm... a few months late with the release

with one caveat: git does not have "native" per-directory restrictions. We can mimic that with a hook, but it's weaker in GIT than in CVS (there is an option to override the hook).

Hummmm, having a look at githoooks(5) manual page it says you can bypass the 'pre-commit' hook, but I don't see any reference to being able to bypass the 'pre-receive' and 'update' hooks on the remote repository.

If you can't bypass them, then we could actually enforce per-directory (or per-file or per-whatever) rectriction on the 'canonical' repository, couldn't we?

Edit: I've just seen a message by Junio C Hamano in Documentation/howto/update-hook-example.txt (in the git source tree) that is titled 'control access to branches' that deals with a similar problem (but in the context of branches, instead of directories/files; it shouln't be too dificult to adapt it to the pre-receive hook for our situation).

Saludos. Iñaki.

Thanks for all this information Martín.

Can you tell us if the mis-match between cvs and git version numbers would be a problem with Jira using a cvs gateway to keep track of the changes happening in all the branches?

At this point, after reading this thread, I think we are still many months away from being able to move without creating chaos in the community.

Let's make a plan anyway..

Mathieu

Except that Jira could work from the read-only CVS mirrors we are going to maintain.

IIRC, Jira already had a GIT integration plugin.

Couple relevant links - looks like there is a mercurial plugin we can quickly grab and, ahem, repurpose...

http://forums.atlassian.com/thread.jspa?threadID=24671&tstart=0

http://jira.atlassian.com/browse/FE-337

At least es.cvs.moodle.org does Beware that compression is disabled to keep the CPU load down (we have lots of bandwith, but the hardware is not that powerful and there are other services running on that machine).

This can impact the firt rsync download a bit, but should not be that noticeable for subsequent rsync operations (if you do them at regular intervals, e.g., daily).

But I'd really recommend cloning the git repo at Catalyst. The CVS import is really heavy, takes a lot of time, and sometimes produces different results from the official CVS repo. The people at Catalyst are doing a good job at managing all those things for a lot of us (specially detecting the repo shift and fixing it). Kudos to them!

On the other hand, if you clone your repo from the repo at Catalyst, you'll have the same history (sharing object 'names' -the SHA1 name-), which eases things quite a bit if you intend to share your modifications with other git users (push and pull operations between repos become possible, and they are much more efficient and less time cosuming and error prone that patches/patch series).

Saludos. Iñaki.

We've been out of Sourceforge for a few months now ... but we never completely updated the documentation to remove all traces of it. I did so after reading your message, finally.

I tested only two servers and the 'eu' mirror doesn't allow rsync, but the 'es' server seems to be ok with it. In any case, the Catalyst Git repository works well, you may want to use it instead of creating one from scratch (and they keep it up to date too...).

Mathieu

I would recommend you continue with your plan.

Learning CVS is a useful skill anyway as it is the benchmark everything else is compared against, and - even if developers change to git - CVS is likely to keep working for end users one way or another.

The most fundamental difference is that Git is a distributed system, i.e. not just the current version, but all previous versions are stored on every machine. In CVS only the server stores all previous versions, your machine just has one version. But there are lots of other differences to do with Git being 20 years newer.

In summary, please go ahead and learn CVS and don't worry about this argument discussion.

--sam

PS Copied from some random site (why yes, it was the first result for my Google search, how did you guess):

Key advantages of Git in general

• Excellent native support of distributed development paradigm
• Collaboration can occur over many media: SSH, HTTP, WebDAV, FTP, or emails (no need to open special port)
• Branching/merging is a native central concept
• Merging is powerful: simple and automatic merging with complete history (and the repo history itself keeps all merging history)
• Robustness: internal file formats are very simple; corruption is very rare and recovery very simple
• It is very fast

Just to add to what Sam says, if you want a good book to introduce you to CVS and version control, Pragmatic Version Control with CVS is a good one. (And no, that Andy Hunt who is an author is not a relation of mine.)

(((Hey! there is now a Pragmatic Version Control with GIT - or at least there will be come September 15th.)))