Program revisions

[yrone]

How do you guys manage changing sourcecode and naming
revisions?

I am just a perl scripter mostly but learning php and mysql. I am not even to the point of running a major project yet! mostly stuff under 2k lines of code.

Even at this small amount of code I start getting confused about versions and whatnot.

Should you name something script v01 and each change you make up the version by 1? I make 100's of changes per session. Should you name it by session? day? feature?

I ask also because some of the revisions that I make get misplaced, misnamed, and other bad things. Let me explain.

I have a script in production that is a mailing list. This runs each morning at 8:45 and works just fine.

I want to move the list of emails from within the script to an external file to make things easier to manage.

I want to test the mailing list beta for a few days and only mail myself and not the others on the list.

Now to migrate the beta to production. move it into the production directory and move the current version to version_previous. and whatnot. After a few times of doing this its going to get crazy!!

How do you manage it? And what about LARGE projects of 10's of thousands of lines of code and revisions and whole featuresets daily???

I know CVS is supposed to deal with this but I dont think that I need that much power yet.

Sorry for the long post

[chrism01]

Well, code control software includes CVS, SCCS, RCS, PVCS etc.
If you're working on a commercial Unix, I recommend SCCS if its there.
For personal/unofficial stuff, just go with the internal header info eg

Take a copy of current prodn SW and add
V1.00
to the header. Save in a dedicated src code dir

Then take another copy, amend to V1.01 and edit/test until you've got a beta. When you want to do a proper beta test, copy V1.01 to the src code dir and copy/release to beta/prodn.

If you need to do more amendments, take a copy of V1.01 (assuming its heading in the right direction), amend to V1.02 , rinse, repeat as above.
You may want to create a version V1.1 for a satisfactory version in prodn (assuming it didn't take 99 betas to fix) ie all "stable prodn vers" are V1.1, V1.2 V1.3 etc.
Intermediate betas would have 2 decimal places eg V1.01, V1.02, etc.

For ease of checking in the src code dir, you could add the ver num to the prog name eg
perl_prog_v1_01.pl
You may/may not want this naming in prodn if other code calls this prog, as the call would have to be updated each time.
You could also put the version num in a global var so that you can prefix all log msgs for later ref.

You can then automate code backup/releases.. :)

Just MHO...

[GaryJones32]

emacs can do version controll for you
not so good for huge projects but a good way to get started with it
basically you got these basic things you do for version controll
register a file
check in a files changes
check out a file (locked editable)
revert a file to a previous state

emacs tries to do the next logical thng as you go

Cntrl-x v v

otherwise you can controll it yourself

Cntrl-x v i to register a file
Cntrl-x v u toss out the last set of changes
Cntrl-x v h insert vc header
Cntrl-x v r check out a named snapshot
Cntrl-x v = generates a version diff report
Cntrl-x v s create a named snapshot
version snapshot names are valid args for all vc commands
Cntrl-x v c throw away a saved revision
Cntrl-x v a edit the change log
Cntrl-x v l look at the change log
Cntrl-x v d shows directory
mark files with m unmark with u to act on more than one file at a time
Cntrl-x v ~ can open multiple versions of the same file in other windows

emacs uses rcs unles it finds another system like cvs are being used on the files