7:30 p.m.
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 :)
--
Armin
feng.shaun(a)gmail.com
"Dare to Dream?"
7:33 p.m.
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!
http://git.or.cz/gitwiki/GitSvnComparsion
7:45 p.m.
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!
http://git.or.cz/gitwiki/GitSvnComparsion
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
8:53 p.m.
On Mon, Sep 29, 2008 at 9:45 PM, Paul W. Frields <stickster(a)gmail.com>wrote:
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!
>
> http://git.or.cz/gitwiki/GitSvnComparsion
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(a)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(a)gmail.com
"Dare to Dream?"
7:39 p.m.
2008/9/29 Armin Moradi <feng.shaun(a)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
5:38 a.m.
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.
5:56 a.m.
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
4:37 p.m.
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."
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A pessimist is a person who has had to listen to too many optimists.
-- Don Marquis
8:52 p.m.
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
11:45 p.m.
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.
--
T o m M i t c h e l l
Found me a new hat, now what?
3:32 a.m.
2008/9/30 Nifty Fedora Mitch <niftyfedora(a)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
4:32 a.m.
On Tue, 2008-09-30 at 04:32 -0400, Thomas Thurman wrote:
2008/9/30 Nifty Fedora Mitch <niftyfedora(a)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
4:46 a.m.
2008/9/30 Ralf Corsepius <rc040203(a)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
5:05 a.m.
On Tue, 2008-09-30 at 05:46 -0400, Thomas Thurman wrote:
2008/9/30 Ralf Corsepius <rc040203(a)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
5:48 a.m.
2008/9/30 Ralf Corsepius <rc040203(a)freenet.de>:
On Tue, 2008-09-30 at 05:46 -0400, Thomas Thurman wrote:
> 2008/9/30 Ralf Corsepius <rc040203(a)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
6:17 a.m.
On Tue, 2008-09-30 at 06:48 -0400, Thomas Thurman wrote:
2008/9/30 Ralf Corsepius <rc040203(a)freenet.de>:
> On Tue, 2008-09-30 at 05:46 -0400, Thomas Thurman wrote:
>> 2008/9/30 Ralf Corsepius <rc040203(a)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
3:32 p.m.
On Tue, Sep 30, 2008 at 04:32:28AM -0400, Thomas Thurman wrote:
2008/9/30 Nifty Fedora Mitch <niftyfedora(a)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
--
T o m M i t c h e l l
Found me a new hat, now what?
.
9:34 a.m.
On Tue, Sep 30, 2008 at 4:32 PM, Nifty Fedora Mitch
<niftyfedora(a)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.
3:10 a.m.
2008/9/29 Armin Moradi <feng.shaun(a)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-cont...
.
peace
T
5687
days inactive
5688
days old
18 comments
9 participants
participants (9)
-
Armin -
Damian S -
Joseph L. Casale -
Michael Semcheski -
Nifty Fedora Mitch -
Paul W. Frields -
Ralf Corsepius -
Thomas Thurman -
Todd Zullinger