use make and version control system for every project?

V

Ville Vainio

Jorge Godoy said:
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.
 
E

Erik Max Francis

John J. Lee said:
So does diff.

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

Jules Dubois

On Mon, 06 Oct 2003 02:00:44 GMT, in article
Personally, I use make on every single one of my projects.
[...]

I'm just the opposite. I don't use make on personal or group Python
programming projects. Would you say why you find it useful there?
Version control, it depends.
[...]

I always, always, always use version control -- _Essential CVS_ calls what
I'm doing "source code control", but I do it anyway. (I'm trying to learn
CVS in between other high-priority processes.)
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.

How about the old-timer RCS?
But if you don't use version control, be sure to make frequent backups

Excellent advice.
 
C

Carl Banks

Jules said:
On Mon, 06 Oct 2003 02:00:44 GMT, in article
Personally, I use make on every single one of my projects.
[...]

I'm just the opposite. I don't use make on personal or group Python
programming projects. Would you say why you find it useful there?


Even my simplest projects have a Makefile looking something like this:

---------------------
install:
python setup.py install --home=~

uninstall:
rm -rf ~/lib/python/package-name

dist:
python setup.py sdist

clean:
rm -rf build dist *~ *.pyc
---------------------

Useful? Yeah. Easiest way to define a bunch of common directives,
and keep the clutter of the project root down? I think so.

It's certainly not crucial.


--
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
 
S

sashan

Roy said:
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.
Well the project has just started and there isn't much code. The
repository has only 6 revisions so it's hard to assess the stability of
subversion. Installation and setup of apache + subversion on windows was
remarkably easy. On the linux (Gentoo) system I do the development on,
installing and setting up a subversion server was a no-brainer. I can't
really give an indepth analysis of it yet, save to say that it's working
for me.
 
P

Peter Hansen

sashan said:
Well the project has just started and there isn't much code. The
repository has only 6 revisions so it's hard to assess the stability of
subversion. Installation and setup of apache + subversion on windows was
remarkably easy. On the linux (Gentoo) system I do the development on,
installing and setting up a subversion server was a no-brainer. I can't
really give an indepth analysis of it yet, save to say that it's working
for me.

Heck, even SourceSafe did *that* much for us, at the time. ;-)

I'd say to Roy just watch for casual references to projects using
subversion (not when someone's pushing subversion, just when someone
happens to mention in passing that subversion is being used). When
you see enough of those to feel like it's fairly widely used, it's
ready for you. There are early adopters, and then there are those
who are busy early-adopting other stuff and can't afford the time and
risk involved in testing out subversion, too. :)

-Peter
 
C

Cameron Laird

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.
.
.
.
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.
Worth repeating. I'm fond of version control,
although not because of customer demands to
look backwards as seems to be true for others.
.
.
.
 
K

Kaz Kylheku

Roy Smith said:
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.
 
P

Peter Hansen

Cameron said:
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
 
A

Aahz

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?
 
A

Aahz

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?
 
A

A.M. Kuchling

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
 
E

Erik Max Francis

Aahz said:
Does Perforce work without a server?

No, but as I said, you can run it without a license with two users and
two client workspaces for free for as long as you want; the client and
server are free to download. See the Licensing section of this page:

http://www.perforce.com/perforce/loadprog.html

You can run the server yourself, you just can't add more than two users
or workspaces -- and for single use, that's often a perfectly acceptable
limitation.

And as I mentioned, you can supposedly qualify for a free license with
open source projects that meet some criteria, but I haven't looked into
it closely myself so I don't know the precise details.
 
M

Michael Geary

No, but as I said, you can run it without a license with two users and
two client workspaces for free for as long as you want; the client and
server are free to download. See the Licensing section of this page:

http://www.perforce.com/perforce/loadprog.html

You can run the server yourself, you just can't add more than two users
or workspaces -- and for single use, that's often a perfectly acceptable
limitation.

BTW, Erik, thank you very much for pointing this out. We use Perforce at
work, and it never had occurred to me that I could use it for my personal
projects as well. Sweet!

-Mike
 
E

Erik Max Francis

Michael said:
BTW, Erik, thank you very much for pointing this out. We use Perforce
at
work, and it never had occurred to me that I could use it for my
personal
projects as well. Sweet!

Yeah, I came across it the same way.
 

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

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top