Hi guys, what's the status on using CVS? I am really afraid that we will branch too much with the allegro branch. Unfortunately I cannot host a CVS server, I only have dialup. Any thoughts? Florian At 19:46 12.11.2002 -0700, you wrote: In article <3DD154D5.2081.8EEDB8@localhost>, Tim Wegner <twegner@swbell.net> writes:
CVS is fundamentally file oriented, not patch or release oriented.
A patch is just a diff. CVS can produce diffs easily. I'm not sure what you mean by "release oriented". A release is a snapshot of the evolving code base made at a point in time. Tags are used to identify the versions of the files in a release.
A typical patch involves several files. There might even be several different patches that affect the same file.
CVS has no problem generating a patch as a diff between two tags. (A tag is just a symbolic name associated with a particular file revision.)
We could recover "patchlevel" information using dates. CVS also has a tag feature that I haven't used.
You could use dates, but tags are easier.
CVS doesn't handle renaming files other than by deleting the old and creating the new (thereby losing the history).
When you delete a file in CVS, it isn't permanently deleted. It goes into the "Attic" and can be regenerated when you check out old versions before the file was deleted. The old file has its revision history intact. The new file starts out with a new revision history. Its true that CVS doesn't have a "rename" command that identifies this scenario. In practice, it hasn't been a problem for me on all the projects I've used CVS for revision control. The first checkin of the new file says something like "see old_file.c for revision history before this file was renamed to new_file.c", and then you look at old_file.c's revision history if you really need to see it. In practice, I found that we really didn't rename files that often and even when we did, we didn't need to look at the revision history of the old file. But it is there, if you need to look at it. You just need to understand how CVS operates to see it. If you really feel its important to have the revision history intact then there are ways you can diddle the Repository directly, but they have drawbacks -- basically they break attemps to check out old versions of the code.
CVS handles binary files poorly (so I have read).
CVS handles ibnary files just fine. What it doesn't know how to do is diff a binary file, so it stores a copy of the file every time you check it in, since it doesn't know how to make a diff. In practice, this wasn't a big problem for us. Things like word documents are binary files, and we simply stored the new version of the document. If you want diffs, then you should convert binary files to a text representation before checking in the file. XML is a nice metastandard for representing all kinds of things as text these days.
Subversion is a program that aims to remedy these defects.
OK, I looked at their home page. It seems interesting, but I don't know that fractint's needs aren't already served by CVS. My instinct is to stick with tools that I know are stable and work. I'm in no rush to adopt a replacement for CVS unless I have a reason. SVN does have a solution for the file rename problem that looks good, but I didn't see anything on their web site about binary diffs. Since fractint doesn't have any binary files (well, there are some .o files, but you don't actually expect that you'll be sending diffs of .o files, right? You diff the assembly that gneerated the .o and send a new .o), I don't think CVS would be cumbersome for fractint. The place where binary files comes up often is using CVS for web sites that have images. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>