Development tools and practices for Pythonistas

[Chris Angelico]

For a single user, there would be no merge issue. And svn is very simple to
use.
That would not be a such bad advice for a beginner with VCS systems.

As someone who for years had "nightly backups and renamed files" as
his only VCS, I would advise beginners to pick up a VCS that they can
learn, master, and then use widely, not one that will be restricted to
solo work (forcing them to learn a different system when they join
some other project). There's no particular benefit in learning older
systems, is there? (I never learned CVS or SVN; my first is git, and
it's the only one I've used to any great extent.)

Oh, and rolling your own VCS can work in specific situations, but it's
probably going to work out a lot more efficient to use a well-known
one, even if it does have a learning curve. I have a few places where
I should probably migrate things to git.

Chris Angelico

 

[Jean-Michel Pichavant]

As someone who for years had "nightly backups and renamed files" as
his only VCS, I would advise beginners to pick up a VCS that they can
learn, master, and then use widely, not one that will be restricted to
solo work (forcing them to learn a different system when they join
some other project). There's no particular benefit in learning older
systems, is there? (I never learned CVS or SVN; my first is git, and
it's the only one I've used to any great extent.)

Oh, and rolling your own VCS can work in specific situations, but it's
probably going to work out a lot more efficient to use a well-known
one, even if it does have a learning curve. I have a few places where
I should probably migrate things to git.

Chris Angelico

You're mistaking, SVN is not restricted to solo work. However it's more
suitable for solo work than git.
Git is just the current buzz about VCS. I guess some people are
switching to it without really knowing what's going on.

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

I tried to search for indicators about VCS usage without finding any but
I think that svn is still one the most used VCS. Anyway it's not about
which one is the most popular, but which one fits your need the best.
For the OP, that would be SVN IMO.

JM

 

[Anssi Saari]

For a single user, there would be no merge issue.

Really? What about a single user with many computers and environments?
I find myself merging files on occasion because I edited them
separately and forgot to check in changes before doing more edits on a
different computer.

 

[Jean-Michel Pichavant]

Really? What about a single user with many computers and environments?
I find myself merging files on occasion because I edited them
separately and forgot to check in changes before doing more edits on a
different computer.

I was talking about merge *issue* i.e merge resulting in conflicts that
are not easy to solve. With a single user most of the merge will be
solved automatically by any decent VCS.

JM

 

[Thomas Rachel]

Am 27.04.2011 13:17, schrieb Jean-Michel Pichavant:

You're mistaking, SVN is not restricted to solo work. However it's more
suitable for solo work than git.

Why?

I personally found hg much better than svn. That's why I migrated all my
projects.


Thomas

 

[Tim Chase]

True enough. But the modern crop of first-tier VCSen – Bazaar,
Git, For a single user, there would be no merge issue. And svn
is very simple to use.

There have been plenty of times I've needed to merge in SVN as a
solo developer. Usually I'll branch off maint. branches and spin
out feature branches. For the maint. branches, I want to apply
hot-fixes to the branch and then merge those hot-fixes into the
dev mainline. For the feature branches, I want to be able to
flip between mainline development and feature development without
one interfering with the other, but then easily pull changes from
one to the other.

And it's always been a pain. While I understand more recent SVN
releases should auto-mark things in a way that merging is less
painful, I find that it doesn't come remotely close to the ease
with which I can merge in other systems.

-tkc

 

[Tim Chase]

Right, that's not a count against Bazaar for at least the last several
versions (since 2009 at least). Bazaar is easily fast enough for
anything people use, say, Mercurial for.

Glad to hear. That was my biggest beef with bzr when I tried it
(c. 2008), so if they've got that working well, it's worth my
time to revisit. Do you have a reference for timing improvements
against version number ("in version x.y, action Z took N ms; in
version x.[y+1], action Z took N-M ms")? I'm running Debian
Stable and sometimes it takes a little while for these features
to trickle down. But I *hope* changes in 2009 would have made it
in by now

Hmm. Can't really overcome the rampant NIH syndrome: there is a lot that
shouldn't *need* so much documentation if the interface were better
designed from the start. I wouldn't count this as a pro for Git.

Yeah, I've encountered that aspect of the abundant documentation
on Git.

I recommend doing so.

Thanks for giving me something to do this weekend.

-tkc

 

[Martin Schöön]

This has been a pretty informative thread so far. Please keep it coming.
I am a hardware development guy and do very little software development.
I have been vaguely aware of tools for version control but inspired by
this thread I have started looking at Mercurial.

My humble contribution (from my boss really) since I have not seen it
mentioned here:
http://code.google.com/p/gource/ (I have zero experience of gource so
there is no point in asking me questions)

/Martin

 

[Tim Chase]

After my passionate Bazaar evangelism?

I must say my takeaway from the thread was (1) check back in on
Bazaar to see if the speed is better than I remember and (2)
Fossil, wha? wow!

-tkc

 

[Daniel Kluev]

I seriously recommend anyone looking for a modern VCS to give Bazaar a
decent trial. It's the one I've found newcomers learn most easily, and
it's astoundingly flexible as one's needs with it grow.

When I was deciding what DVCS I should use for personal projects, Bzr
was first thing I tried. It was quite uncomfortable experience after
svn, esp. with branches and merges, working not the way I was
expecting it to.
Mercurial, on the contrary, did exactly what I was expecting it to,
and was overall very easy to learn.

 

[Hans Georg Schaathun]

Hmmm. I am still using svn.

How easy and reliable is it to import my svn version history into
one of the three big DVCS-s mentioned here?

I am fairly happy with svn, but then I use it more as a backup system
and a means to synchronise multiple systems. Something better would
not hurt, but loosing the version history would ...

I am particularly interested in git, not because of any qualities it
may have but because that's what my colleague pushes, and he seems
to be pushing our students into it, so it would be useful for me to be
familiar with it.

 

[Tim Chase]

How easy and reliable is it to import my svn version history
into one of the three big DVCS-s mentioned here?

I'd say that one of the things SVN has going for it is that it's
the lingua-franca of VCSes, so just about everything (especially
the 3 big names mentioned in this thread: hg, bzr, git) can talk
to svn pretty uneventfully. As a matter of fact, last I checked,
Django is hosted in SVN, but most of the developers use DVCS
tools to check in/out from the main repository to their own local
hg/bzr/git repos, do their work locally (with the option to work
offline, branch/merge easily, etc), and then push changesets back
up when they have a patch they're happy with.

-tkc

 

[Kevin Walzer]

Fossil is another SCM to consider: http://www.fossil-scm.org/

It's written by the author of SQLite, D. Richard Hipp. It's not as
well-known as some of the other DCVS's, but the Tcl/Tk language projects
have moved their core development to it (http://core.tcl.tk). This is
relevant to Python because Tkinter is part of the stlib.

There aren't any huge sites like Github providing Fossil hosting, but
here is one site: http://chiselapp.com/

--Kevin

 

[D'Arcy J.M. Cain]

Bazaar's support for Subversion repositories is great (it requires the
‘bzr-svn’ plug-in, of course). Use the ‘svn-import’ subcommand to import
an entire Subversion repository to a Bazaar repository with all branches
and history intact.

Anyone know how to go the other way? I recently converted all my
projects over to svn from cvs and then took over another project that
uses bzr. I would prefer everything to be in the same system.

 

[Hans Georg Schaathun]

I'd say that one of the things SVN has going for it is that it's
: the lingua-franca of VCSes, so just about everything (especially
: the 3 big names mentioned in this thread: hg, bzr, git) can talk
: to svn pretty uneventfully. As a matter of fact, last I checked,
: Django is hosted in SVN, but most of the developers use DVCS
: tools to check in/out from the main repository to their own local
: hg/bzr/git repos, do their work locally (with the option to work
: offline, branch/merge easily, etc), and then push changesets back
: up when they have a patch they're happy with.

I am not sure I get the implications right. Are you suggesting that
I could keep my svn server, switch to a DVCS client, and reap the
benefits?

 

[Daniel Kluev]

We were looking for some simple integrated SCM, issue tracker and wiki
in our university for software design and software testing courses,
and fossil seems to be perfect match, thanks for sharing.

 

[Tim Chase]

: I'd say that one of the things SVN has going for it is that it's
: the lingua-franca of VCSes, so just about everything (especially
: the 3 big names mentioned in this thread: hg, bzr, git) can talk
: to svn pretty uneventfully. As a matter of fact, last I checked,
: Django is hosted in SVN, but most of the developers use DVCS
: tools to check in/out from the main repository to their own local
: hg/bzr/git repos, do their work locally (with the option to work
: offline, branch/merge easily, etc), and then push changesets back
: up when they have a patch they're happy with.

I am not sure I get the implications right. Are you suggesting that
I could keep my svn server, switch to a DVCS client, and reap the
benefits?

Yep...some are plugins while others are stock/native, but you can
read your fill at

Git:
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

Mercurial:
http://mercurial.selenic.com/wiki/WorkingWithSubversion

Bazaar:
http://doc.bazaar.canonical.com/plugins/en/svn-plugin.html


-tkc

 

[Hans Georg Schaathun]

I was talking about merge *issue* i.e merge resulting in conflicts that
: are not easy to solve. With a single user most of the merge will be
: solved automatically by any decent VCS.

Exactly, and with svn that can be a true nightmare when directories
are involved. The rumour is that git handles this much better.


I call it a rumour not because I doubt it (I don't), but because
I have not seen for myself.

 

[Martin Schöön]

After my passionate Bazaar evangelism?

Before I think as I remember I was quick out of the blocks.

I seriously recommend anyone looking for a modern VCS to give Bazaar a
decent trial. It's the one I've found newcomers learn most easily, and
it's astoundingly flexible as one's needs with it grow.

I'll take look but so far I have found Mercurial pretty easy to get to
grips with. But then I have only done fairly trivial stuff.

/Martin

 

[CM]

A lone developer using such a VCS reaps the benefits of this by getting
good merging support.

While we're on the topic, when should a lone developer bother to start
using
a VCS? At what point in the complexity of a project (say a hobby
project, but
a somewhat seriousish one, around ~5-9k LOC) is the added complexity
of
bringing a VCS into it worth it?

I've been making changes to code and saving changes to the same
files,
but backing up on Dropbox, which keeps 30 days of previous saves.
I've rarely had to resort to undoing code by calling up a previous
save.
I test each new change as it is made to see if it breaks anything
(not
automatic testing, though), and I don't collaborate with anyone else
as
yet.

Should I bother to try a VCS?