views:

58

answers:

3

I use revision control tools to handle ever changing versions of my webpage, LaTeX documents, as well as actual source code, but I don't think I'm doing it right. I used cvs for a while, then git more recently, but I'm not really happy with them, possibly because I'm using them incorrectly. I'd like some advice on how to use them correctly, or a suggestion for a different type of tool.

Basically, I'd like to use source control as an persistent long term "undo" feature that I can easily browse. For example, if I had a Java project in eclipse, it would be nice if I could see side-by-side views of the current file and an earlier version with options to completely revert or cut and paste from the old. In terms of something like a webpage tree, I'd like to see side by side views of a tree and revert to old versions of files or bring back a whole directory that was earlier deleted.

Right now I basically do a git add .; git commit -a every time I make major changes and know that I can restore some old versions of files if I need. Whenever I've actually had to go back and browse the revision tree it seemed complicated. I've tried a few GUIs in the past, including a web-based CVS viewer, but it still seemed harder than it needed to be.

Am I doing it wrong? Or is there a different tool I should be using?

+1  A: 

I can answer part of your question: gitk, ugly though it be, is the most featureful of the GUIs and it comes bundled with Git. It allows you to view differences between two different revisions.

siride
Thanks, I fired it up and must have seen it in the past. It doesn't look that bad...
Rich
+2  A: 

Git definitely works best if you make commits that are logical changes to your code. This is so that you can (a) tell what they are later, and (b) pick and choose them if you need to. If you just wholesale commit everything that's changed since some arbitrary point in the past, then it's unsurprising that your commit history looks complicated.

I would suggest practicing using Git to try to make small, self-contained commits every time you change something. Not only will you find your project history more sensible, but you will be well practiced in the most important part of source control when the time comes where you need to collaborate with others using a source control system.

Greg Hewgill
Thanks, this rings of good advice.
Rich
A: 

I'd like to differ from my fore-speakers.

I use old RCS for singe file things, like dotfiles, config files and small projects.

I know it's old and not used wildly anymore, but for small things only used by one person, it's great. I'ts very easy to use, and takes almost zero preliminary configuration. I use ci -o and co -l to use the rcs.

polemon