So I wanted to know about the public opinions on which one is better, Git or
Subversion as versioning control system (VCS?). If you can, please come up with some reasons too! Like what benefits do you think your preferred one has that the other one doesn't offer!
answers are very much appreciated :)
So I wanted to know about the public opinions on which one is better, Git or Subversion as versioning control system (VCS?). If you can, please come up with some reasons too! Like what benefits do you think your preferred one has that the other one doesn't offer!
On Mon, Sep 29, 2008 at 06:33:20PM -0600, Joseph L. Casale wrote:
So I wanted to know about the public opinions on which one is better, Git or Subversion as versioning control system (VCS?). If you can, please come up with some reasons too! Like what benefits do you think your preferred one has that the other one doesn't offer!
I started with CVS and soon after moved to SVN, which was quite an improvement. However, I recently learned git and would *never* go back. For starters, it's *much* faster than any other system. The use of branches is completely phenomenal. And the ability to quickly set up and host a repository for anyone with just some file copies to any HTTP share is worth its weight in gold.
On Mon, Sep 29, 2008 at 9:45 PM, Paul W. Frields stickster@gmail.comwrote:
On Mon, Sep 29, 2008 at 06:33:20PM -0600, Joseph L. Casale wrote:
So I wanted to know about the public opinions on which one is better,
Git or
Subversion as versioning control system (VCS?). If you can, please come
up
with some reasons too! Like what benefits do you think your preferred
one has
that the other one doesn't offer!
I started with CVS and soon after moved to SVN, which was quite an improvement. However, I recently learned git and would *never* go back. For starters, it's *much* faster than any other system. The use of branches is completely phenomenal. And the ability to quickly set up and host a repository for anyone with just some file copies to any HTTP share is worth its weight in gold.
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Yes, actually recently I'm trying to learn git, and it makes a lot more sense to do the experimental stuff in a branched repository and then merge it in when it's done!!
Thanks for the responses guys, again, very appreciated! I hope this thread would be of help to some other people too, although I would still like more responses from more people ;) -- Armin feng.shaun@gmail.com "Dare to Dream?"
2008/9/29 Armin Moradi feng.shaun@gmail.com:
So I wanted to know about the public opinions on which one is better, Git or Subversion as versioning control system (VCS?).
There is no "better". There is "different".
git (and bzr, and hg, and others) are distributed VCSs. They have a fundamentally different model to svn and CVS.
With svn and CVS, there is one master repository and all developers check out from it and commit to it as necessary.
With git and bzr and hg and so on there are many repositories. Any of these can be merged with any other. This can be one repo which is considered the master and one on each developer's own machine, in which case they behave similarly to svn and CVS. However, you still have the extra feature that a developer can commit to zir own repository without committing to the master, and commit to the master only when the work is ready to share.
If what you need is what svn does, and your coders all know svn, then you can use svn. If you have a large number of developers who do a lot of work on different branches, or who spend a lot of time away from the net on aeroplanes and so on, then you should use a distributed VCS like git or bzr or hg.
If you're trying to pick what to use for a new project, it's quite likely the hosting arrangements for that project will dictate what you can use anyway.
peace
T
There is no "better". There is "different".
Exactly. I happily use SVN on my projects which only I commit to. Although I am the only committer, this code needs to be pushed out to multiple machines, both public and private. I'll still use SVN if I get several other collaborators, but once there are more than 3 or 4 people committing, I'll move to git which uses a superior model for large numbers of committers.
FWIW, SVN was not designed to be the 'best'. It was meant to be a better CVS than CVS, and in that goal, succeeded.
On Tue, 2008-09-30 at 20:38 +1000, Damian S wrote:
There is no "better". There is "different".
Exactly. I happily use SVN on my projects which only I commit to. Although I am the only committer, this code needs to be pushed out to multiple machines, both public and private. I'll still use SVN if I get several other collaborators, but once there are more than 3 or 4 people committing, I'll move to git which uses a superior model for large numbers of committers.
3 or 4 people are not many, it's "sightly above 1" :)
It's an amount of users any VCS should be able to handle.
FWIW, SVN was not designed to be the 'best'. It was meant to be a better CVS than CVS, and in that goal, succeeded.
A matter of perspective.
From my point of view, on the client side, the only real advantage that
SVN has over CVS is it allowing renaming files and it being less demanding on very low bandwidth or very poor connections to the server.
SVN's major "con" is it being comparatively generous on local diskspace and it polluting a checked out source trees with huge amount of VCS-metadata files (git, mercurial do so as well).
Ralf
Ralf Corsepius wrote:
SVN's major "con" is it being comparatively generous on local diskspace and it polluting a checked out source trees with huge amount of VCS-metadata files (git, mercurial do so as well).
Git and mercurial both keep their files in one top-level dir, e.g. .git or .hg. This doesn't count as "polluting the tree" in my mind. It's certainly not as annoying as the "CVS" dirs that CVS puts all over my tree.
Sure, the disk space is higher for a git clone than for a CVS checkout, but with git you are getting the entire history of the project instead of just one working copy as you do with CVS (or Subversion) -- I consider this a free backup with each checkout. The advantage of not having to wait for diffs and logs across a network is well worth the disk space. And, if you're developing on a single box holding the repository and working copy, both CVS and Subversion generally use more disk space than git does -- with Subversion being significantly worse than CVS in this area.
Git is also very efficient with regards to storage. I have often found that an entire git repository is significantly smaller than a single Subversion working copy. As another point of information, according to http://git.or.cz/gitwiki/GitSvnComparsion, "the Mozilla project's CVS repository is about 3 GB; it's about 12 GB in Subversion's fsfs format. In Git it's around 300 MB."
On Tue, 2008-09-30 at 17:37 -0400, Todd Zullinger wrote:
Ralf Corsepius wrote:
SVN's major "con" is it being comparatively generous on local diskspace and it polluting a checked out source trees with huge amount of VCS-metadata files (git, mercurial do so as well).
Git and mercurial both keep their files in one top-level dir, e.g. .git or .hg.
Try a recursive grep in a checked-out source tree (grep -R <pattern> .)
This was easily applicable with CVS/RCS, but is hardly applicable with SVN, Git or mercurial - Certainly, this is nothing serious, nevertheless it's "nagging to loose a once applicable habit"
This doesn't count as "polluting the tree" in my mind. It's certainly not as annoying as the "CVS" dirs that CVS puts all over my tree.
Does the name of the directory matter? Does the fact that CVS doesn't hide its directories make a difference?
Sure, the disk space is higher for a git clone than for a CVS checkout, but with git you are getting the entire history of the project instead of just one working copy as you do with CVS (or Subversion)
Well this doesn't scale well on big source trees (e.g. Fedora's) or one with a long history (e.g. GCC's).
Just one figure:
An SVN checkout (from GCC) # du -s -b gcc-4_3-branch 832684026 gcc-4_3-branch
Size of an uncompressed tarball containing approximately the same sources (~ size of a hypothetical CVS checkout) # du -s -b gcc-4.3.2 369871768 gcc-4.3.2
Ralf
On Mon, Sep 29, 2008 at 09:30:39PM -0300, Armin Moradi wrote:
So I wanted to know about the public opinions on which one is better, Git or Subversion as versioning control system (VCS?). If you can, please come up with some reasons too! Like what benefits do you think your preferred one has that the other one doesn't offer! answers are very much appreciated :) --
Read about Mecurial and RCS.
This is a BIG topic.... and you need to disclose the size of the team and their preferences.
If it is just you.... use RCS.
If it is your company look at bitkeeper (not free) and understand fully why kernel folks switched. If you have the budget give it a hard look. t
If you are joining a project hook up with what ever tree tools are used up stream. All of them let you generate diffs that you can send into the maintainer.
If you are a public company look into CVS and a well managed well firewalled server and more...
Mecurial should be on your short list.
2008/9/30 Nifty Fedora Mitch niftyfedora@niftyegg.com:
On Mon, Sep 29, 2008 at 09:30:39PM -0300, Armin Moradi wrote:
So I wanted to know about the public opinions on which one is better,
Read about Mecurial and RCS.
This is a BIG topic.... and you need to disclose the size of the team and their preferences.
If it is just you.... use RCS.
Out of interest, why do you recommend RCS over, say, svn or git or bzr for a personal project? I've been using bzr for a while for one-off projects (which never need pushing to other machines than the one I'm working on) and it works fine without ever using the distributed-ness.
T
On Tue, 2008-09-30 at 04:32 -0400, Thomas Thurman wrote:
2008/9/30 Nifty Fedora Mitch niftyfedora@niftyegg.com:
On Mon, Sep 29, 2008 at 09:30:39PM -0300, Armin Moradi wrote:
So I wanted to know about the public opinions on which one is better,
Read about Mecurial and RCS.
This is a BIG topic.... and you need to disclose the size of the team and their preferences.
If it is just you.... use RCS.
Out of interest, why do you recommend RCS over, say, svn or git or bzr for a personal project?
I for one am still favoring CVS for several reasons:
* I am used to using it for a very long time and am familiar with it. * CVS (and RCS) archives can be converted/exported to almost all other VCS if required. * CVS (and RCS) have proven their longevity. Their bugs and deficiencies are widely know and understood. This does not necessarily apply to most VCSes. * I don't need a distributed VCS. * CVS clients are widely available, many (most) users are least to some extend familiar with it.
If I was new to VCS's, I'd set up a local testbed of typical use cases and evaluate the candidates. My personal candidates would be CVS, SVN, git and mercurial.
All have pros and cons. None of them meets everybody's preferences and use-cases.
I've been using bzr for a while for one-off projects (which never need pushing to other machines than the one I'm working on) and it works fine without ever using the distributed-ness.
The point which has never let appear bzr attractive to me is it being an exotic niche => Likely fine for local use, but I would not consider it as basis for a larger project.
Ralf
2008/9/30 Ralf Corsepius rc040203@freenet.de:
- CVS (and RCS) archives can be converted/exported to almost all other
VCS if required.
Are CVS and RCS archives equivalent?
The point which has never let appear bzr attractive to me is it being an exotic niche => Likely fine for local use, but I would not consider it as basis for a larger project.
I think you misunderstand bzr. Bzr is a generic distributed VCS, roughly equivalent to git.
peace
Thomas
On Tue, 2008-09-30 at 05:46 -0400, Thomas Thurman wrote:
2008/9/30 Ralf Corsepius rc040203@freenet.de:
- CVS (and RCS) archives can be converted/exported to almost all other
VCS if required.
Are CVS and RCS archives equivalent?
IIRC, widely. However I have to admit, my last encounter with RCS dates back to more than a decade, so ... ;)
The point which has never let appear bzr attractive to me is it being an exotic niche => Likely fine for local use, but I would not consider it as basis for a larger project.
I think you misunderstand bzr. Bzr is a generic distributed VCS, roughly equivalent to git.
Well, my point is "lack of a userbase", "availability of clients on different platforms", "integration in IDEs", "VCS providers offering it" So far, I have never tripped over a major project which is actively using bzr nor have I ever met a user using it :)
Or differently: Don't underestimate the "familiarity factor" when launching a new archive.
More generally speaking, I'd claim, nowadays, * older projects with a long history tend to use CVS (with a strong tendency to switch to SVN), * most projects dating back several years use SVN, * many newer (often Linux focused) projects use git. * mercurial is on the loose * bzr never made it out of its niche
The big question however is: What are the OP's use-cases.
Ralf
2008/9/30 Ralf Corsepius rc040203@freenet.de:
On Tue, 2008-09-30 at 05:46 -0400, Thomas Thurman wrote:
2008/9/30 Ralf Corsepius rc040203@freenet.de:
- CVS (and RCS) archives can be converted/exported to almost all other
VCS if required.
Are CVS and RCS archives equivalent?
IIRC, widely. However I have to admit, my last encounter with RCS dates back to more than a decade, so ... ;)
Which is why I was wondering why you were recommending it over CVS, you see.
I think you misunderstand bzr. Bzr is a generic distributed VCS, roughly equivalent to git.
Well, my point is "lack of a userbase", "availability of clients on different platforms", "integration in IDEs", "VCS providers offering it" So far, I have never tripped over a major project which is actively using bzr nor have I ever met a user using it :)
You might not be a fan of MySQL or Ubuntu, but I don't really see how they qualify as not being major.
As for "availability of clients on different platforms": one particular case I've run into was a company I worked at recently where they decided to go for bzr over git. When I started I asked what their rationale had been, and they told me it was because some of their developers ran *nix and some ran Windows. They found at the time that bzr had better cross-platform support (possibly because of being written in an interpreted language). Perhaps CVS is even more widely ported, though, merely by virtue of being older.
Or differently: Don't underestimate the "familiarity factor" when launching a new archive.
Very true. This is occasionally a very good reason to stick with svn (or even CVS, although svn is practically a drop-in replacement for CVS and solves many of its infelicities). If a user has *no* previous VCS experience, there's no reason not to start them off on a distributed VCS but not use all its features straight away, though.
The big question however is: What are the OP's use-cases.
Also very true.
peace
Thomas
On Tue, 2008-09-30 at 06:48 -0400, Thomas Thurman wrote:
2008/9/30 Ralf Corsepius rc040203@freenet.de:
On Tue, 2008-09-30 at 05:46 -0400, Thomas Thurman wrote:
2008/9/30 Ralf Corsepius rc040203@freenet.de:
- CVS (and RCS) archives can be converted/exported to almost all other
VCS if required.
Are CVS and RCS archives equivalent?
IIRC, widely. However I have to admit, my last encounter with RCS dates back to more than a decade, so ... ;)
Which is why I was wondering why you were recommending it over CVS, you see.
I think you misunderstand bzr. Bzr is a generic distributed VCS, roughly equivalent to git.
Well, my point is "lack of a userbase", "availability of clients on different platforms", "integration in IDEs", "VCS providers offering it" So far, I have never tripped over a major project which is actively using bzr nor have I ever met a user using it :)
You might not be a fan of MySQL or Ubuntu, but I don't really see how they qualify as not being major.
OK, I wasn't aware about them using bzr ;)
OTOH, GCC is using SVN, openSUSE seems to be using SVN, Debian seems to be using Git.
As for "availability of clients on different platforms": one particular case I've run into was a company I worked at recently where they decided to go for bzr over git.
So far, git hasn't convinced me, either ;)
When I started I asked what their rationale had been, and they told me it was because some of their developers ran *nix and some ran Windows. They found at the time that bzr had better cross-platform support (possibly because of being written in an interpreted language). Perhaps CVS is even more widely ported, though, merely by virtue of being older.
CVS support can be found in almost all IDEs and also is available for most OSes.
Or differently: Don't underestimate the "familiarity factor" when launching a new archive.
Very true. This is occasionally a very good reason to stick with svn (or even CVS, although svn is practically a drop-in replacement for CVS and solves many of its infelicities).
Well, at least to me, GCC having switched to SVN (some years back) had caused massive drawbacks on my work on GCC. So I would not agree to "SVN being a drop-in replacement for CVS". It has very similar features, but the CLI is entirely different.
Ralf
On Tue, Sep 30, 2008 at 04:32:28AM -0400, Thomas Thurman wrote:
2008/9/30 Nifty Fedora Mitch niftyfedora@niftyegg.com:
On Mon, Sep 29, 2008 at 09:30:39PM -0300, Armin Moradi wrote:
So I wanted to know about the public opinions on which one is better,
Read about Mecurial and RCS.
This is a BIG topic.... and you need to disclose the size of the team and their preferences.
If it is just you.... use RCS.
Out of interest, why do you recommend RCS over, say, svn or git or bzr for a personal project? I've been using bzr for a while for one-off projects (which never need pushing to other machines than the one I'm working on) and it works fine without ever using the distributed-ness.
I like RCS for its simplicity. It is not a distributed system yet you can generate and send context diffs that others you are working with can apply (see patch). To this end much of the early usenet opensource was managed with RCS. It also can establish the foundations for revision control ethics in an organization. There is no need to set up a server. Just fundamental revision control. It is well tested and as bug free as any.... It is easy to back up a project to DVD/CDROM or to a tar file.
Looking down the list of replies...I see that one reply stated that his preference was ..____.. because he knows how to use it. Of all the reasons to pick a tool that is the best reason of all.
RCS has one key advantage. The current text is present in the file and in a pinch you can quickly edit the file to recover your source. No SQL no special file system hooks. Some licensed systems require you to have a current license to see your code or migrate your code's history to another system.
The simplicity of the archives permit editing. In some audit mandated environments a server managed by others, processes and procedures are required. For these environments a cautious review is in order to comply with regulations or contract requirements..... most are easy to address with a project backup to DVD/CDROM or to a tar file, signed, sealed and delivered.
Search the web for Walter Tichy's paper on RCS .vs. SCCS. http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps
On Tue, Sep 30, 2008 at 4:32 PM, Nifty Fedora Mitch niftyfedora@niftyegg.com wrote:
RCS has one key advantage. The current text is present in the file and in a pinch you can quickly edit the file to recover your source. No SQL no special file system hooks. Some licensed systems require you to have a current license to see your code or migrate your code's history to another system.
I think this is one of the most useful points about RCS (and CVS). The repository is useful by itself. With git or svn, the files are stored as binary objects, and it is not plainly obvious how to get from binary back to the head version in the event of repository corruption or some other disaster.
There may be a mode like this for SVN, but to my knowledge it is not the default.
2008/9/29 Armin Moradi feng.shaun@gmail.com:
So I wanted to know about the public opinions on which one is better, Git or Subversion as versioning control system (VCS?). If you can, please come up with some reasons too! Like what benefits do you think your preferred one has that the other one doesn't offer!
Elijah Newren made a good series of apparently unbiased comparisons recently, beginning at http://blogs.gnome.org/newren/2007/11/15/starting-to-compare-version-control... .
peace
T
-
Armin -
Damian S -
Joseph L. Casale -
Michael Semcheski -
Nifty Fedora Mitch -
Paul W. Frields -
Ralf Corsepius -
Thomas Thurman -
Todd Zullinger