Version Control Software


C

cutems93

I am looking for an appropriate version control software for python development, and need professionals' help to make a good decision. Currently I am considering four software: git, SVN, CVS, and Mercurial. Of course, I already did some research on different characteristics of version software, but I concluded that listening to personal experiences and opinions from the professionals will help me a lot. What version control software do you like the most and why? What is the difference between git and Mercurial? Also, ifanyone can help me by doing google-chat or skype, please let me know.

Thanks in advance!
 
Ad

Advertisements

J

Joel Goldstick

git or hg. but git is most popular and very easy to learn. Its also great
for distributed develpment
 
C

Chris Angelico

I am looking for an appropriate version control software for python development, and need professionals' help to make a good decision. Currently I am considering four software: git, SVN, CVS, and Mercurial. Of course, I already did some research on different characteristics of version software, but I concluded that listening to personal experiences and opinions from the professionals will help me a lot. What version control software do you likethe most and why? What is the difference between git and Mercurial? Also, if anyone can help me by doing google-chat or skype, please let me know.

Don't touch CVS unless you absolutely have to. SVN is also distinctly
old now. The three most popular modern source control systems are git,
hg, and bzr (Bazaar). Of the three, I would remove Bazaar from
consideration unless you're posting to a Canonical repository;
Mercurial and git are superior, in my experience.

Between those two (hg and git), though, it's really hard to call. I'm
personally familiar with git, and it serves me well; others have the
same experience with hg. Either will do you fine. They have some
different features, eg git detects file moves after the event while hg
prefers to be told about them up-front, but for normal daily tasks,
either is fine. Pick based on which one other people near you are
familiar with, so that you can get help when things go wrong - for
instance, I would be utterly useless when it comes to hg (I can't even
make patch files, which I can do just fine with git).

But above all, do use source control. The difference between that and
not is way WAY more than the difference between one system and another
:)

ChrisA
 
T

Tim Chase

[much of my reply echos Chris but elaborate]

Don't touch CVS unless you absolutely have to. SVN is also
distinctly old now.

SVN had its place, but branching/merging is a pain (well, branching is
pretty easy, it's the merging that hurts).
Mercurial and git are superior, in my experience.

Between those two (hg and git), though, it's really hard to call.
I'm personally familiar with git, and it serves me well; others
have the same experience with hg. Either will do you fine.

A few pros (+) and cons (-) from my experiences:

+hg: much easier to transition from CVS/SVN as the command-line
syntax/structure matches much more closely

-git: the command-line interface feels rather distant from the
CVS/SVN classics

+hg: better cross-platform (i.e., including Win32) support

-git: a bit persnickity on Win32

-hg: last I checked, can't do octopus merges (merges with more than
two parents)

+git: can do octopus merges

-/+ hg: certain power-user functionality is relegated to plugins that
you need to activate (though many come standard, you have to activate
them) This can be a plus if you don't want to have a foot-gun within
easy reach; this can be an annoyance if you regularly use those sorts
of tools appropriately (particularly the partial-commit that "git add
-p" provides)

+git: the internal data model is pretty simple making it easy to
understand where things stand and the status of various branches

+git: having multiple remotes and managing them feel a little easier
to me than with Mercurial (YMMV)

+hg: written in Python (with optional C component for some
CPU-intensive work, but can run without it if you don't have
compile-rights on a particular machine that does already have Python
installed)

-git: a hodge-podge of C, Perl, shell-scripts and other madness.
This is part of the Win32 ding above.

+hg: Python devs have chosen Mercurial as their VCS of choice

+hg: bitbucket hosting

+git: github, gitorious, bitbucket hosting

+git, +hg: both have lots of big-name projects using them

+git, +hg: both have reasonably painless ways of talking to
repositories of other flavors (git can talk to CVS/SVN/hg repos; hg
can talk to CVS/SVN/git repos)

+git, +hg: documentation on both is top-notch (git's available
documentation has radically improved since it's grand suckage before
1.6; once 1.6 landed, git was far less user-hostile)


Given the choice, I eventually settled on git (after about 3-4
serious attempts to learn it, then giving up for a couple months and
retrying) unless I have to involve Win32 machines, as I like the
power it provides and how easy it is to understand in my head.
On Win32, I tend to bias towards Mercurial. There are still some
aspects of Mercurial's internal models that leave me scratching my
head and rummaging through the docs (public vs. private branches,
bookmarking, preferring cloning to make branches) and surrendering
occasionally on more obscure things I know that I *should* be able to
do. That said, if you just want solid VCS behavior and already know
CVS/SVN, Mercurial will give you an easier transition.

And I believe most of what can be said about Mercurial can also be
said about Bazaar (bzr), though it seems to have less mindshare,
except perhaps among Ubuntu developers, as it has tighter integration
with LaunchPad.

Fortunately, since git/hg/bzr are all free, you can download them all
and kick the tires to see which one fits YOU (the OP) best.

-tkc
 
T

Tim Chase

I am looking for an appropriate version control software for python
development, and need professionals' help to make a good decision.

While I'm generally a git user (see my other email), I'll also put in
a plug for Fossil <http://fossil-scm.org/> which has a single binary
(making it easily installed), as well as an integrated bug-tracker &
wiki, and can be dropped onto a server as a CGI program with almost no
effort. And it's primary author, Richard Hipp is famous for creating
sqlite, and for the rigorous testing under which both tools go.

-tkc
 
R

Roy Smith

cutems93 said:
I am looking for an appropriate version control software for python
development, and need professionals' help to make a good decision. Currently
I am considering four software: git, SVN, CVS, and Mercurial.

CVS is hopelessly obsolete. SVN pretty much the same.

Git and Mercurial are essentially identical in terms of features; which
you like is as much a matter of personal preference as anything else.
Pick one and learn it.
 
Ad

Advertisements

C

cutems93

Thank you everyone for such helpful responses! Actually, I have one more question. Does anybody have experience with closed source version control software? If so, why did you buy it instead of downloading open source software? Does closed source vcs have some benefits over open source in some part?

Thanks!
MinS
 
R

rusi

Thank you everyone for such helpful responses! Actually, I have one more question. Does anybody have experience with closed source version control software? If so, why did you buy it instead of downloading open source software? Does closed source vcs have some benefits over open source in some part?

Thanks!
MinS

Not too many people who buy expensive software use it.
Those who use it, have usually not been party to buying it.

The first are usually called 'boss'.
The second, 'programmer' or some euphemism for that like 'software-
engineer.'

As to your question about vcs, there is also fossil:
http://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki
 
R

Roy Smith

cutems93 said:
Thank you everyone for such helpful responses! Actually, I have one more
question. Does anybody have experience with closed source version control
software? If so, why did you buy it instead of downloading open source
software? Does closed source vcs have some benefits over open source in some
part?

This really doesn't have anything to do with python. Someplace like
http://en.wikipedia.org/wiki/Comparison_of_version_control_systems would
be a good starting point for further research.

If I were to buy a closed-source VCS today, I would look at Perforce
(www.perforce.com). I used it for several years. For small teams, you
can download and use it for free, so you can play with it without
commitment.

Perforce tries to solve a somewhat larger problem than just version
control. They also do configuration management. You can set up a
config-spec which says, "Give me this bunch of files from branch A, that
bunch of files from branch B, and some third bunch of files which have
some specific tag. And, while you're at it, remap the path names so the
directory structure looks like I want it to".

This configuration management can be a powerful tool when working on a
huge project. We threw *everything* into our p4 repo, including the all
the compilers, development toolchains, and pre-built binaries for all
the third-party libraries we used. We also used a single repo shared by
all the development groups (many 100's of developers on three
continents). I would never want to do that in a system like git or hg;
every developer would have to drag down 100's of GB of crap they didn't
need. With p4, we could build people config-specs so they got just the
parts they needed.

It is also a bit of a steep learning curve to figure out. Only a few
people were trusted to do things like build config-specs and create
shared branches.

As a company, Perforce is a dream to work with. Their tech support was
pretty awesome. I would shoot off an email to (e-mail address removed), and
I don't think it ever took more than 5 or 10 minutes for me to get a
response back from somebody. And that somebody would inevitably be
somebody who knew enough to solve my problem, not just some first-line
support drone.

The costs aren't outrageous, either. The pricing is a little
complicated (initial license, annual renewal, various support options,
of them on a sliding scale based on quantity). I seem to remember it
working out to about $100/developer/year for us, but we were buying in
fairly large quantities.
 
M

MRAB

Thank you everyone for such helpful responses! Actually, I have one
more question. Does anybody have experience with closed source
version control software? If so, why did you buy it instead of
downloading open source software? Does closed source vcs have some
benefits over open source in some part?
I've used Microsoft SourceSafe. I didn't like it (does anyone? :)).
 
Ad

Advertisements

R

rusi

You should be wary of GitHub, a very popular Git hosting site. It uses
what amount to proprietary protocols, which encourage using GitHub's
specific interface instead of native Git for your operations and hide a
lot of the needless complexity; but this results in a VCS repository
that is difficult to use *without* being tied to that specific site,
killing one of the best reasons to use a DVCS in the first place.

bitbucket -- originally only Hg based -- now supports Hg or git.
And for small private (non open source) repos its more affordable
http://tilomitra.com/bitbucket-vs-github/
 
T

Tim Chase

13.06.13 05:41, Tim Chase напиÑав(ла):

Actually it is possible in Mercurial.

Okay, then that moots this pro/con pair. I seem to recall that at
one point in history, Mercurial required you to do pairwise merges
rather than letting you merge multiple branches in one pass.

-tkc
 
R

Rui Maciel

Roy said:
CVS is hopelessly obsolete. SVN pretty much the same.

I would say that SVN does have its uses, but managing software repositories
isn't one of them due to the wealth of available alternatives out there
which are far better than it.

Git and Mercurial are essentially identical in terms of features; which
you like is as much a matter of personal preference as anything else.
Pick one and learn it.

I agree, but there is a feature Git provides right out of the box which is
extremelly useful but Mercurial supports only as a non-standard module: the
git stash feature.


Rui Maciel
 
R

Roy Smith

Tim Chase said:
Okay, then that moots this pro/con pair. I seem to recall that at
one point in history, Mercurial required you to do pairwise merges
rather than letting you merge multiple branches in one pass.

-tkc

So, I guess the next questions is, why would you *want* to merge
multiple branches in one pass? What's the use case? I've been using
VCSs for a long time (I've used RCS, CVS, ClearCase, SVN (briefly),
Perforce, Git, and hg). I can't ever remember a time when I've wanted
to do such a thing. Maybe it's the kind of thing that makes sense on a
huge distributed project with hundreds of people committing patches
willy-nilly?

How would hg even represent such a multi-way merge? Doesn't every
revision have exactly one or two parents?
 
Ad

Advertisements

G

Grant Edwards

These days there is no good reason to use CVS nor Subversion for new
projects. They are not distributed (the D in DVCS), and they have
specific design flaws that often cause insidious problems with common
version control workflows. As a salient example, branching and merging
are so painful with these tools that many users have learned the
terrible habit of never doing it at all.

I agree that branch/merge handling in svn is primitive compared to git
(haven't used hg enough to comment).

The last time we made the choice (4-5 years ago), Windows support for
get, bzr, and hg was definitely lacking compared to svn. The lack of
something like tortoisesvn for hg/git/bzr was a killer. It looks like
the situation has improved since then, but I'd be curious to hear from
people who do their development on Windows.
 
C

Chris Angelico

The last time we made the choice (4-5 years ago), Windows support for
get, bzr, and hg was definitely lacking compared to svn. The lack of
something like tortoisesvn for hg/git/bzr was a killer. It looks like
the situation has improved since then, but I'd be curious to hear from
people who do their development on Windows.

I do almost exclusively Linux dev, but occasionally nip onto Windows
for one reason or another (possibly inside a virtual machine). It's
possible to get git for Windows, including gitk and 'git gui' (not
sure about any other graphical tools, they're the only two I use), but
the most convenient way to use them is from a ported bash.
Fortunately, the installer will provide all of that, putting a 'Git
Bash' entry into the Start menu, and for someone who's come from Linux
anyway, working in bash is quite welcome.

ChrisA
 
G

Grant Edwards

I do almost exclusively Linux dev, but occasionally nip onto Windows
for one reason or another (possibly inside a virtual machine). It's
possible to get git for Windows, including gitk and 'git gui' (not
sure about any other graphical tools, they're the only two I use), but
the most convenient way to use them is from a ported bash.
Fortunately, the installer will provide all of that, putting a 'Git
Bash' entry into the Start menu, and for someone who's come from Linux
anyway, working in bash is quite welcome.

Unfortunately, something that requires typing commands would not fly.
I mostly use svn via command line and sometimes via meld, but for some
others (even one Linux developer), if it can't be done done entirely
from a GUI, then it isn't going to get done.

If it wasn't for Cygwin, I'd never be able to accomplish much of
anything in Windows. :)
 
Ad

Advertisements

C

Chris Angelico

Unfortunately, something that requires typing commands would not fly.
I mostly use svn via command line and sometimes via meld, but for some
others (even one Linux developer), if it can't be done done entirely
from a GUI, then it isn't going to get done.

If it wasn't for Cygwin, I'd never be able to accomplish much of
anything in Windows. :)

Check out 'git gui' then - and in the Windows build, that's in the
Start menu directly. I usually use git gui only for partial commits
(it's more convenient than 'git add -p' when the parts to commit and
the parts to not-commit are right next to each other), but it can be
your full console. For those who like the graphical things in life,
it's a good choice.

That and gitk for viewing the repo. I use gitk *all the time*, at work
and on my own projects, because it is excellent. (Actually I use a
minorly-patched gitk; must remember to submit the patch upstream some
day.)

ChrisA
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top