Version control on single files?

Kaos

[H]ard|Gawd
Joined
Oct 14, 2003
Messages
1,328
I'm researching adding some form of version control to some scripts that I manage for sanity's sake.

I have many shell scripts in a single directory that all operate as a single standalone script (essentially, each one is unique). When I make changes I'm usually changing one at a time.

Maybe I'm missing it or a lightbulb hasn't clicked yet but I've been toying with SVN but any time I change any script and then commit (merge maybe) it ups the version of the whole "trunk" up, even if I changed just a single script.

I'm guessing this is just an understanding issue where Im missing some kind of concept.

Would you guys mind helping me fill in the mental gap? I've done a little googling but think I need a discussion on the subject.

Thanks!
 
CVS does version control on a file by file basis. CVS is also a project that has been end of life for awhile. That file-by-file model seems to have fallen out of favor though as its successor SVN, and SVN's successors (DSCM style source-control) use a changeset based model.

Honestly, If it were me I'd probably use Mercurial or some other DSCM software (Git, Bazaar). They work great for projects of all sizes and are easier to manage (imo) than SVN.
 
if you update one file, the revision for that file and the folder in which it resides will increment. the other files will stay at their current revision. if you update a different file though, the revision for that different file and the folder in which it resides (talking about the same parent folder as the first file) will be 1 more than whatever the highest previous revision was. so basically revisions for individual files won't be continuous if you modify a different file first.

i guess i've long-windedly explained (to my understanding) what you seem to basically understand already. i suppose part of the idea is that for most projects, you want to retrieve a snapshot of the entire folder as it was at a particular time. in your case you only care about it on a file-by-file basis, but it would also be silly to make a separate repository for each individual file.

basically i think it's just a "get used to it" kind of thing.

SVN and i'm sure every version control system worth a crap lets you see the changelog/history of a single file at a time, which seems to be the more important thing you might be interested in.
 
Just use SVN, or git/mercurial and let go of the idea that advancing the number of the whole trunk is bad. It's not.

You can still pull up the change history on a file by file basis.
 
Thanks for the responses. I talked with the developers who are in the process of planning their move from CVS to something distributed and we're going to come along for the ride so to speak.

Our stuff isn't as complex as theirs so that's a blessing (since the majority of my group is just writing perl or shell scripts with some of my PHP projects tacked onto it).

The good thing is that I'll get my hands dirty with people who have the experience, which is how I learn best.
 
unless you primarily use windows, then use mercurial. Mercurial works well on both linux and windows, git sucks on windows.
 
unless you primarily use windows, then use mercurial. Mercurial works well on both linux and windows, git sucks on windows.

heh, the only way I use git on windows is by SSHing into my local dev server and committing
 
Back
Top