use make and version control system for every project?

[AK]

Hi, I recently read an advice here that one should try to use make and
version control system even if you're the only one working on the
program. Is that a good advice? How many of you do that?

Thanks,

-AK

 

[Carl Banks]

Hi, I recently read an advice here that one should try to use make and
version control system even if you're the only one working on the
program. Is that a good advice? How many of you do that?

Personally, I use make on every single one of my projects. I even use
make to run setup.py in my pure Python packages. (Cause it's just
easier to 'type make install' than 'python setup.py install--home=~'.)
It's not necessary, but it can save a lot of work and keep everything
up-to-date.

Version control, it depends. I've used CVS for some personal projects
before, and can't say I've ever found it useful, and it's definitely a
pain to keep things up-to-date. I recommend, for personal projects,
not bothering with version control at least until the project is
fairly stable.

But if you don't use version control, be sure to make frequent backups
(and store the backups on another medium; hard disks crash; it
happened to me).


my-2-cents-ly yr's,

--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[Erik Max Francis]

Hi, I recently read an advice here that one should try to use make and
version control system even if you're the only one working on the
program. Is that a good advice? How many of you do that?

Yes, and yes. All my Web sites and programs are built with make, even
my resume (of which a few variations are built from templates and then
each is automatically converted to a bunch of formats).

Using source control, even for your solitary projects, is always
advisable: you get a little touch of automatic backups (particularly if
your source control server is on a different machine), as well as the
ability to work on different branches simultaneously and have
authoritative information on precisely what you did to your software and
when.

 

[Peter Hansen]

Hi, I recently read an advice here that one should try to use make and
version control system even if you're the only one working on the
program. Is that a good advice? How many of you do that?

I don't use make with Python, but I use it with anything
compiled, as with embedded development.

I *always* use CVS at this point, and I deeply regret the years that
I spent not using it and the many varied ways in which I made negative
progress because of that (lost files, incompatibilities that could not
be resolved between various versions of things, inability to identify
exactly when and why a given thing was done, etc).

I _strongly_ recommend learning to use CVS, or *any equally simple
version control system*, even for personal projects, so that it becomes
second nature early on and you never find yourself without it.

-Peter

 

[Roy Smith]

Version control, it depends. I've used CVS for some personal projects
before, and can't say I've ever found it useful, and it's definitely a
pain to keep things up-to-date. I recommend, for personal projects,
not bothering with version control at least until the project is
fairly stable.

I suppose this is a personal preference kind of thing, but I use
revision control (CVS or RCS mostly, Clearcase when they hold a gun to
my head) for everything, from the very beginning. Source code,
documents, test notes, project plans, it all goes under revision
control. I check stuff in often and early.

I do that even if it's just something I'm working on for myself. It
might be a little silly, but that's what I've found works well for me.
For any project with more than one person working on it, however, you
would be insane not to use some sort of revision control system.

I find it gives me a lot of value. There's the built-in backups
(although, the CVS repository itself needs to be backed up). There's
the running commentary of the checkin messages (I'm pretty anal about
trying to keep a good checkin log). There's the ability to branch a
file to explore some experimental changes. If you don't like CVS, there
are plenty of other revision control systems to look at, ranging from
free to mega-bucks.

I don't see a whole lot of value for make in a python project. I use it
myself mostly to drive unit test suites, but that's more force of habit
than anything else. I should probably replace those Makefiles with
python scripts If you don't like make (and there's plenty not to
like), there are other, newer, systems around like Ant and Jam that are
worth looking at.

Of course, none of this really has much to do with Python. These are
all generic software engineering issues.

 

[Ben Finney]

Hi, I recently read an advice here that one should try to use make and
version control system even if you're the only one working on the
program. Is that a good advice? How many of you do that?

Definitely, to both questions.

The 'make' tool allows automation of project building and other tasks,
which is immensely useful whether you work alone or not.

Revision control alows you to checkpoint particular revisions of the
project (or parts thereof) in a way much more transparent than copying
files around manually.

And you never know which lone-gun projects will require additional help,
so placing all of them under revision control and automated build will
allow you to bring people in much more easily.

 

[Carl Banks]

I suppose this is a personal preference kind of thing, but I use
revision control (CVS or RCS mostly, Clearcase when they hold a gun to
my head) for everything, from the very beginning. Source code,
documents, test notes, project plans, it all goes under revision
control.

Best yet, the OP should probably try it and see if it works for him.

I recommended not bothering early on because I tend to move files
around quite a bit early on (a major pain in CVS), and I suspect I'm
not the only person to do that. But if he's the type of person whose
projects are "fairly stable" in the very beginning, by all means, he
should CVS away.

[snip]

There's the running commentary of the checkin messages (I'm pretty
anal about trying to keep a good checkin log).

Incidentally, this is probably greatest strength of version control
relative to frequent backups (for personal projects, of course). It's
also a feature I've found extremely little use for. I mean, it sounds
cool to be able to go back and see exactly when you made a certain
change, but is that really useful in practice?

I'm sorry, but my pragmatic mind tells me it's all wasted effort, a
lot of work for little benefit. Frequent backups do well enough for
me, with far less effort, so it's what I've been moving towards.

But whatever works for you. And, of course, the OP should try it and
decide if it works for him.


--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[Ben Finney]

I recommended not bothering early on because I tend to move files
around quite a bit early on (a major pain in CVS), and I suspect I'm
not the only person to do that.

That's a flaw of CVS, not of revision control. Other revision control
systems (Arch, Subversion, even RCS) don't suffer from this flaw; use
any of those to have *no* excuse not to use revision control from the
project's inception.

Incidentally, this is probably greatest strength of version control
relative to frequent backups (for personal projects, of course). It's
also a feature I've found extremely little use for. I mean, it sounds
cool to be able to go back and see exactly when you made a certain
change, but is that really useful in practice?

It's more than cool.

A change history is vital on a fast-changing project; you can see when a
particular feature went in, when a bug was fixed, when a structural
change was made, etc.

A change history is vital in multi-developer projects (though that's not
what the OP asked about) to supplement fallible human memory.

A change history is required by many free software licenses (the GPL
being one) when you change another's work.

Sound useful enough?

 

[Carl Banks]

That's a flaw of CVS, not of revision control. Other revision control
systems (Arch, Subversion, even RCS) don't suffer from this flaw; use
any of those to have *no* excuse not to use revision control from the
project's inception.

Well, I've never used Arch or Subversion, so I can't evaluate them.
I'd expect too much moving files around to be a headache in general
(even if the system used is a lot better than CVS), but maybe those
other systems make it effortless. (shrug).

It's more than cool.

A change history is vital on a fast-changing project; you can see when a
particular feature went in, when a bug was fixed, when a structural
change was made, etc.

Why is that important? How often do you really need to know when a
bug was fixed, for example? (I'm serious. I've never needed to know
these things. Do other people really use these features for personal
projects? And if they do, is it really that often?)

A change history is vital in multi-developer projects (though that's not
what the OP asked about) to supplement fallible human memory.

It's not what I was talking about, either. Of course, version control
is needed if there's more than a few people working on something.

A change history is required by many free software licenses (the GPL
being one) when you change another's work.

Well, that's certainly a good enough reason to use it, when such a
situation occurs.

Sound useful enough?

I don't know. Reasons B and C don't apply to most personal projects,
and I'm not convinced of the usefulness of Reason A.


--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[David Mertz]

|Ben Finney wrote:
|> A change history is vital on a fast-changing project; you can see when a
|> particular feature went in, when a bug was fixed, when a structural
|> change was made, etc.

|Why is that important? How often do you really need to know when a
|bug was fixed, for example? (I'm serious. I've never needed to know
|these things. Do other people really use these features for personal
|projects? And if they do, is it really that often?)

I've been maintaining my package Gnosis Utilities for a couple years
now. It's a real public project--used by a fair number of people, and
with contributions from a couple dozen. Not a -huge- project, but more
than trivial. A bit less than a meg of pure Python and textual
documentation (I forget now what good LOC counters are, I know I tried a
couple in the past).

I've never gotten around to using any sort of version control system.
Well, unless you count keeping archives of all the old releases on my
web site. Of course, I've also never really given anyone else "check in
priviledges" either (there are some contributors I trust quite a lot--
but even there, I still eyeball their code, and make sure I understand
what it does, why it does it, and that I like the comments and variable
names).

In those couple years, I think I have wondered about exactly when a
particular fix went in exactly ONCE. Finding the answer was more
work than it should have been, I suppose. I had to glance through a
couple old versions. Actually, even then it was more about trying to
remember some old API details for backward compatibility, not really a
date question.

YMMV, of course. And I certainly think something larger and/or more
corporate should use version control. But I'm with Carl in not really
getting it for small semi-personal projects.

Yours, David...

 

[Tim Churches]

YMMV, of course. And I certainly think something larger and/or more
corporate should use version control. But I'm with Carl in not really
getting it for small semi-personal projects.

I would have said so too, but 6 months ago I had occasion to work
jointly on some Python code (about 6000 lines worth) with a programmer
working under contract to my employer. He was located in Melbourne
(Australia), I was (at the time) in Manila (Philippines). Code was
stored on a CVS server in Melbourne, which I accessed via a dial-up
Internet connection from my ancient Linux laptop. I was doubtful at
first, but the whole thing worked a treat over a three week period. At
times both of us were working on the different parts of the same Python
module (i.e the same file), and to my amazement CVS merged the changes
made by both of us with very few conflicts and little need for revision
of the merged code.

The biggest source of difficulty was my (continuing) insistence on using
tab characters for Python indenting, whereas my co-programmer preferred
his tab key to introduce a string of 4 spaces...

--

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA/gSuIeJFGqer5k9ARAuHKAKDgIHLPLqBfrq3ZwyG3IrSP1Fse7ACggG0c
1LS9aZQqlYxJHB4+R5xABdc=
=vm9r
-----END PGP SIGNATURE-----

 

[Max M]

Why is that important? How often do you really need to know when a
bug was fixed, for example? (I'm serious. I've never needed to know
these things. Do other people really use these features for personal
projects? And if they do, is it really that often?)

There is a difference in personal projects, and projetcs done by an
individual. If you just write something for your own use it might not
matter much.

But if you write something for customers, or something that other people
use, it is a good idea to be able to tell the customer what changes are
made in the latest version they have received.

It can also be an advantage when billing.

regards Max M

 

[sashan]

Hi, I recently read an advice here that one should try to use make and
version control system even if you're the only one working on the
program. Is that a good advice? How many of you do that?

Thanks,

-AK

Ever since I was introduced to revision control I've used it for
individual projects. I've used/use SourceSafe, Bitkeeper, cvs and
subversion. I recommend that you use some form of revision control for
the following reasons:

1) It's a good habit to get into. If you eventually end up on a team
you'll use revision control so practicing with an individual project
isn't going to hurt.
2) Backups - a revision control system becomes your back up tool.
3) Difftools - sometimes you have make a change to a file and a few days
latter a bug apears in your code. With revision control you can do a
diff between the current file and any previous version to see what
change introduced the bug.
4) Tags/Labels - When you're satisfied with the progress of your project
you can label the repository as say version 1.0. This marks all the
files in the repository as version 1.0. Then at a later date you can
easily go back to the source tree as it was when you finished version 1.0.

I worked for a short time with a company that didn't use revision
control (and these were people who were meant to have 5 to 10 or so
years in IT industry experience.) Their source tree was simply put on a
shared server. The number of developers working on that tree at the same
time ranged from 1 to 4 so it was manageable, but it still sucked. I
tried to explain how to use sourcesafe and setup a server to the guy in
charge of development but I don't think he got it. They were all VB
programmers so I guess that explains their incompetence.

Personally I use Bitkeeper for most of my work now. Since I work
sometimes at home and sometimes at uni it's nice to be able to store my
code/thesis on a server that I can access from anywhere. It also saves
me having to maintain backups. I'm also using Subversion for a part-time
contract I'm working on. I occasionally use cvs since I have a little
neglected project on sourceforge. I've haven't used sourcesafe in a
while. I recommend using Bitkeeper or Subversion because they can track
renames of files. cvs can't and iirc neither can sourcesafe.

 

[Jorge Godoy]

I _strongly_ recommend learning to use CVS, or *any equally simple
version control system*, even for personal projects, so that it becomes
second nature early on and you never find yourself without it.

I second that.

CVS also solves problems of identifying what is the little thing that
you changed and made your program stop running the way it should.

It also makes it easier to backup projects: you only need to backup
the CVS repository on the server.

Planning and integrating programs also is easier (no matter if the
language supports a centralized installation such as Python and Perl
do or not).


With regards to make, I believe that distutils would be its
equivalent in pythonia. It is somewhat unintuitive in some things, but
is a good tool. And helps generating an installable 'package' with
your code, making it easier to share it.

 

[Jorge Godoy]

Why is that important? How often do you really need to know when a
bug was fixed, for example? (I'm serious. I've never needed to know
these things. Do other people really use these features for personal
projects? And if they do, is it really that often?)

Maybe your client calls you and says that the program is not working
as it should and say that he doesn't know the number of his version
immediately, but he remembers it was installed one or two weeks
ago... You remember solving such a bug, but when?

It's not what I was talking about, either. Of course, version control
is needed if there's more than a few people working on something.

To me, 'few = 0', but to you it might be 'few = 1' or more... This
varies from group to group too. We had a team that worked synced and
that could have 5 developers working very fine just by themselves, but
another team required a version control system for just 2 of
them...

Revision control systems are not a substitute for project management
and meetings.

 

[Holger Krekel]

Well, I've never used Arch or Subversion, so I can't evaluate them.
I'd expect too much moving files around to be a headache in general
(even if the system used is a lot better than CVS), but maybe those
other systems make it effortless. (shrug).

JFYI, subversion makes this quite effortless because it basically
is a transactional filesystem. 'svn mv' will work just like 'mv'
in unix when you are moving stuff around in your working-copy. Of
course, you still have to commit 'svn ci' to make the moves
persistent.

cheers, holger

 

[John J. Lee]

CVS also solves problems of identifying what is the little thing that
you changed and made your program stop running the way it should.

So does diff.

I tried CVS for personal work and found it more pain that it was
worth. I can believe other VC systems are sufficiently better to make
it worthwhile, though (moving directories around).


[...]

With regards to make, I believe that distutils would be its
equivalent in pythonia. It is somewhat unintuitive in some things, but

Not really -- scons is the equivalent.


John

 

[Jorge Godoy]

So does diff.

For using diff I'd have to keep several copies os my full
project. With CVS I just keep one full copy -- the last revision ---
and diffs to each revision (it's automatic). The space saved is
substantial for a big sized project.

I tried CVS for personal work and found it more pain that it was
worth. I can believe other VC systems are sufficiently better to make
it worthwhile, though (moving directories around).

I'm biased towards CVS, I'm sorry.

On the other hand, I've been hearing great things about subversion. I
just need to check if there are nice clients to it on Windows too
(some partners of mine only use Windows...).

[...]

With regards to make, I believe that distutils would be its
equivalent in pythonia. It is somewhat unintuitive in some things, but

Not really -- scons is the equivalent.

Hmmm... I should have a look into them. Thanks for the correction.

 

[Roy Smith]

I'm also using Subversion for a part-time contract I'm working on.

How's that working out? I've been watching the subversion project for
several years with interest, but so far havn't worked up the courage to
actually use it for anything.

I'm mostly happy with CVS, except for a few things. High on the list is
the inability to move files around, as others have mentioned. I know
subversion fixes that one. Sounds like an interesting system, but it's
hard to get a good feel for how solid the thing is from reading the
release notes. It's hard to abandon an old tool that mostly works well
without a lot of confidence in the new one.

 

[anton muhin]

On the other hand, I've been hearing great things about subversion. I
just need to check if there are nice clients to it on Windows too
(some partners of mine only use Windows...).

Yes, and they are really nice IMHO.

regards,
anton.