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]

AK wrote:

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]

AK wrote:

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.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Every path has its puddle.
\__/ (an English proverb)

[Peter Hansen]

AK wrote:

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]

Carl Banks <im*****@aerojockey.invalid> wrote:

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]

On Mon, 06 Oct 2003 01:40:38 GMT, AK wrote:

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.

--
\ "Better not take a dog on the space shuttle, because if he |
`\ sticks his head out when you're coming home his face might burn |
_o__) up." -- Jack Handey |
Ben Finney <http://bignose.squidly.org/>

[Carl Banks]

Roy Smith wrote:

Carl Banks <im*****@aerojockey.invalid> wrote:

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.

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]

On Mon, 06 Oct 2003 03:08:57 GMT, Carl Banks wrote:

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?

--
\ "Last year I went fishing with Salvador Dali. He was using a |
`\ dotted line. He caught every other fish." -- Steven Wright |
_o__) |
Ben Finney <http://bignose.squidly.org/>

[Carl Banks]

Ben Finney wrote:

On Mon, 06 Oct 2003 03:08:57 GMT, Carl Banks wrote:

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.

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).

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.

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.

Carl Banks <im*****@aerojockey.invalid> wrote previously:
|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...

--
mertz@ _/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: \_\_\_\_ n o
gnosis _/_/ Postmodern Enterprises \_\_
..cx _/_/ \_\_ d o
_/_/_/ IN A WORLD W/O WALLS, THERE WOULD BE NO GATES \_\_\_ z e

[Tim Churches]

On Mon, 2003-10-06 at 17:43, David Mertz wrote:

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/gSuIeJFGqer5k9ARAuHKAKDgIHLPLqBfrq3ZwyG3IrSP1Fse7A CggG0c
1LS9aZQqlYxJHB4+R5xABdc=
=vm9r
-----END PGP SIGNATURE-----

[Max M]

Carl Banks 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?)

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]

AK wrote:

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.

--
sashan
http://www.cs.auckland.ac.nz/~sgov008/

[Jorge Godoy]

Peter Hansen <pe***@engcorp.com> writes:

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.

--
Godoy. <go***@metalab.unc.edu>

[Jorge Godoy]

Carl Banks <im*****@aerojockey.invalid> writes:

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.

--
Godoy. <go***@metalab.unc.edu>

[Holger Krekel]

Carl Banks wrote:

Ben Finney wrote:

On Mon, 06 Oct 2003 03:08:57 GMT, Carl Banks wrote:

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.

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]

Jorge Godoy <go***@metalab.unc.edu> writes:

Peter Hansen <pe***@engcorp.com> writes: [...] 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]

jj*@pobox.com (John J. Lee) writes:

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.

--
Godoy. <go***@metalab.unc.edu>

[Roy Smith]

sashan <ma***@operamail.com> wrote:

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]

Jorge Godoy wrote:

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.

[Ville Vainio]

Jorge Godoy <go***@metalab.unc.edu> writes:

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's also a nice way to get a concrete idea of what lines of code
correspond exactly with a "feature".

BTW, if you are running CVS, you just *have* to run ViewCVS. It seems
that once you start running it, ViewCVS doubles the benefits you get
from running CVS.

--
Ville Vainio http://www.students.tut.fi/~vainio24

[Cameron Laird]

In article <m3************@ieee.org>,
Jorge Godoy <go***@metalab.unc.edu> wrote:

Carl Banks <im*****@aerojockey.invalid> writes:

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?

I'm skeptical about claims of such use cases. In the
'80s and before, we heard a lot of things on the order
of: "what if the user comes back and says he needs
this error fixed immediately, but only this one error,
and nothing else can change?" Well, yes, if accomoda-
tion of such incidents, or even the more plausible one
Mr. Godoy describes, is a requirement, then, yes,
there's good reason for all that functionality source-
control systems offer.

My own view is that those scenarios were only signifi-
cant for a brief interval, when our cost structure of
installed-software vs. developers vs. hardware vs. ...
hit a neighborhood we'll never again visit. I don't
doubt *at all* that people are still saying these
sorts of things; Mr. Godoy's example is quite apt, in
that sense. The correct solution to it, though, lies
more in the plane of customer relations.

How often "do you need to know when a bug was fixed"?
Often, still; it certainly arises. For the most
part, though, in 2003 there's a healthy emphasis on
making what's right in front of us--the current
version--correct, rather than just "fixing bugs".
'Least, I like to think that.

[Kaz Kylheku]

Roy Smith <ro*@panix.com> wrote in message news:<ro***********************@reader2.panix.com> ...

sashan <ma***@operamail.com> wrote:

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.

Subversion appears to support file renaming, until it's time to merge!

Meta-CVS has element renaming that is robust and mergeable.

http://users.footprints.net/~kaz/mcvs.html
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.

That's why I developed Meta-CVS on top of the CVS substrate---low risk
and instant gratification!

This is vaguely analogous to, say, building multi-media-enabled e-mail
on top of RFC-822 and SMTP, rather than inventing new protocols. You
encode the properties that you want in the data representation
supported by the existing ones, and then do all the work in the
clients.

In the case of CVS, this goes a long way, because you can represent a
lot in text files, such as a directory structure with permissions and
symbolic links. You just need a smart client that knows how to put
that information into action in your sandbox.

[Peter Hansen]

Cameron Laird wrote:

How often "do you need to know when a bug was fixed"?
Often, still; it certainly arises. For the most
part, though, in 2003 there's a healthy emphasis on
making what's right in front of us--the current
version--correct, rather than just "fixing bugs".

While I agree with this positive view, I have to note that it is,
to some people (I believe mostly those involved in commercial
development), quite important to know when a bug was injected.

The reason I say that is because _we_ often spend a moment, after
we have found and fixed the bug of course, investigating why the
bug occurred in the first place.

We like to know who did it, roughly when, and if possible why.

None of this is to place blame, per se, but merely to ensure that
our process receives periodic scrutiny so we can improve it when
it fails us. If the person who checked in the buggy code didn't
work with a partner, we need to fix that. If the partners who
checked in the buggy code didn't test adequately, we need to fix
that. If the customer didn't write an acceptance test that
covered this potential problem, we need to fix that.

We also need to know *when* so we can estimate the risk to our
customers. How many have received code with the defect? Have
we just detected a business-critical risk, or do we have only one
or to field-fixes which have to be organized?

Basically, having the history does often -- for us -- prove
useful and is therefore an important part of what the revision
control system provides for us.

(Much less important on personal projects, but as I mentioned
before, getting in the habit can be difficult so doing this whenever
possible is a Good Thing, even if the direct value is not so clear.)

-Peter

[Holger Krekel]

Kaz Kylheku wrote:

Roy Smith <ro*@panix.com> wrote in message news:<ro***********************@reader2.panix.com> ...

sashan <ma***@operamail.com> wrote:

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.

Subversion appears to support file renaming, until it's time to merge!

Huh? I do it all the time. what do you mean specifically?

holger

[Aahz]

In article <sl*******************************@iris.polar.loca l>,
Ben Finney <bi****************@and-benfinney-does-too.id.au> wrote:

On Mon, 06 Oct 2003 03:08:57 GMT, Carl Banks wrote:

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.

How well does Subversion work without a web server? The docs seem to
imply that you need one, but I'd be using it only in local mode. How
would you choose between Arch and Subversion?
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[Aahz]

In article <3F***************@alcyone.com>,
Erik Max Francis <ma*@alcyone.com> wrote:

Sure. But source control (CVS or not; for personal use I use Perforce)
makes this process streamlined and automatic. Without it, if you want
incremental diffs you have to remember to make a copy of each revision
of each file you edit, naming them meaningfully for future. Source
control gets you this automatically, as well as allowing you to do
things like conveniently create branches, merge them back in to the main
line, etc.

Why Perforce? Isn't that $$$ code?
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[A.M. Kuchling]

On 12 Oct 2003 11:13:26 -0400,
Aahz <aa**@pythoncraft.com> wrote:

How well does Subversion work without a web server? The docs seem to
imply that you need one, but I'd be using it only in local mode. How
would you choose between Arch and Subversion?

Subversion can work on local file storage; in that case, all you need is the
'svn' binary.

My capsule summary of Subversion: works OK, though occasionally the database
gets corrupted in a way that requires running a lock cleanup script. (It
should be emphasized that these corruptions haven't ever resulted in data
loss for me.) SVN is handicapped by being a complete bear to compile,
especially the server; it's much easier to just run Debian unstable, which
has Subversion, than to struggle with compiling Apache2 + neon + Subversion.

I've read the Arch tutorial and intend to experiment with it, because it
looks promising, but don't have any actual experience using it. It looks
*much* easier to make a repository publicly available with Arch than with
Subversion. Some of its filename conventions are a bit goofy, but that can
be lived with.

--amk

[Erik Max Francis]

Aahz wrote:

Why Perforce? Isn't that $$$ code?

Not for small (two or fewer users, two or fewer cleints) or open source
projects.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ But in matters fundamental / We are patterned on an old design
\__/ Oleta Adams