Hi mvoelker,
Points taken. Thanks!
I have evaluated all the cvs I could find but unfortunately I cannot find the functionality I need.
The functionality I need is really straightforward. I just want to store changes and be able to produce any selected revision - no branches, tags, releases, etc.
Here is a program I want (with a little tweaking) but I do not know the language :(
http://www.lyra.org/piperm
Basically, it must run from the command line, ie.
cvsParser someCVSfile.c,v 1.1 --> this will spit out the revision 1.1 from the RAW CVS file someCVSfile.c,v
cvsMake someCVSfile_changed.c someCVSfile.c someCVSfile.c,v --> this will merge changes made in someCVSfile_changed.c to the latest revision someCVSfile.c and produce the RAW CVS file someCVSfile.c,v
I think it is not hard to code the stuff, but I am hoping somebody has done this already to save me the trouble.
It will be seldom (~ once/quarter) that programmers want to retrieve past revisions.
hec",)
Main Topics
Browse All Topics





by: mvoelkerPosted on 2004-02-18 at 08:40:24ID: 10394031
Geeez, you're serious about this, aren't you? You're going to write a version control system on your own which is an insanely complex task. I strongly suggest running an already established version control system (have a look at subversion if you don't like cvs and don't want to pay for it - http://subversion.tigris.o rg)
If you really want to code something on your own - here's how you most pressingn problems could be solved:
1. Add an additional column to the main database table for the revision (and probably date, comment and so on). The primary key for a certain version would then be the module name and its revision. The client software that retrieves/stores versions will have to take care of assigning new version numbers as appropriate (you could also use stored procedures if you like).
2. The client will have to use utitlities like the unix diff/patch (available for windows) to determine the differences between two files. The client would use the edited file, retrieve the latest version from the version control system, compare them using diff, prepare a patch against the latest version with diff and store only that patch as the new revision.
3. When doing a checkout/update operation, your client will retrieve the *oldest* revision (which is not a patch) *and* all available patches, apply those to the old version and thus get the latest version.
Optimizations
- You could reverse the process and always store the latest version of a file and apply backward-patches.
- You could implement a "cache" table for the latest version of files (storing the already patched files), saving time on checkouts
The advantage of this approach is that it saves a lot of space in your database, since you're only storing one version of the file and lots of patches. On the downside all operations are going to take longer the longer your project runs (the more revisions you have). And there are many more problems ahead (branches, tags, releases, packages,...). Be warned - you're in trouble if you write your own version control system (even if it starts for only a few people and a small project - it's gonna grow faster than you like).
You've been warned - best of luck! Feel free to ask for clarifications,
- michael