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>
Florian asked:
what's the status on using CVS?
I have a list of patches going back a long way. I am interested in merging that into a CVS source tree. However my time is limited and I can't promise a deadline. The good news is that I have started using CVS at work, which means that I am getting up to speed on it.
I am really afraid that we will branch too much with the allegro branch.
This is probably true, but CVS won't solve this problem. Many people have wanted to rewrite the code base, bit so far no one has had the combination of time, energy, and skill. However, I agree that once we have mqade a fork of the old program that we want to go ahead with, CVS would be essential. I can make this happen for the old code base, since several people have brought this up, I guess I better move on it! :-) For the new code base, we need a good starting point. Tim
In article <3E6B4911.19897.12313AF@localhost>, Tim Wegner <twegner@swbell.net> writes:
[...] Many people have wanted to rewrite the code base, bit so far no one has had the combination of time, energy, and skill.
While I didn't want to rewrite the code base (I'm not -that- much of a masochist! :-), I did make a fairly extensive change with the driver layer :) -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
Rich wrote:
While I didn't want to rewrite the code base (I'm not -that- much of a masochist! :-), I did make a fairly extensive change with the driver layer :)
These changes could probably be backported into the main source tree. However there are some fractint features that are so closely coupled to video that they might pose a problem (e.g. orbits or inverse julia windows). I recall a story a while ago about an opinion of a fairly iconoclastic software mover and shaker (wish I could remember who it was) who said that legacy code should be treated with respect. It represents uncounted hours of development and debugging, and when people see its defects and bravely sugeest total rewrites, the effort is almost always under-estimated. The whole refinement effort has to be redone. On the other hand, whenever code is touched that area of code can be refactored. And one can make architectural changes - I've done it with fractint several times myself :-) Tim
In article <3E6B8995.19900.21F2231@localhost>, Tim Wegner <twegner@swbell.net> writes:
These changes could probably be backported into the main source tree.
Agreed. They're not that extensive in the sense that they are mostly single line changes sprinkled throughout the source.
However there are some fractint features that are so closely coupled to video that they might pose a problem (e.g. orbits or inverse julia windows).
I'd have to double check the source to be sure, but I painstakingly studied every single piece of fractint source that did any video I/O. It all goes through a set of functions which in the DOS port are coded in assembly. That's how xfractint managed to get things ported to X11 -- they replaced all those assembly functions with C versions that did something X-ish. What I did was the same thing, just pushing it a little farther so that instead of calling a function directly, they call the function through a pointer to a struct containing function pointers, with the struct pointer being a global for the "current driver". This at least gets you to the point where you could switch drivers on the fly.
I recall a story a while ago about an opinion of a fairly iconoclastic software mover and shaker (wish I could remember who it was) who said that legacy code should be treated with respect. It represents uncounted hours of development and debugging, and when people see its defects and bravely sugeest total rewrites, the effort is almost always under-estimated. The whole refinement effort has to be redone.
I totally agree with this sentiment, which is why I started that driver layer effort by studying the source code intensively. Its a huge pile of printout! However, doing this made me appreciate the size of the task and the necessity for "going slow, one step at a time" on the way towards a reincarnated fractint that behaved like a native application on window systems and like the traditional fractint on a DPMI DOS port.
On the other hand, whenever code is touched that area of code can be refactored. And one can make architectural changes - I've done it with fractint several times myself :-)
Refactoring is good! -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
Totally agree on the 'dont touch a running system' maxime. I am in charge of a C-based software product that's been in existance for 10 years now, and I know how easy it is to break things... I also like 'refactoring' ,) Florian
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Rich Sent: Monday, March 10, 2003 2:04 AM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] Re: CVS
In article <3E6B8995.19900.21F2231@localhost>, Tim Wegner <twegner@swbell.net> writes:
These changes could probably be backported into the main source tree.
Agreed. They're not that extensive in the sense that they are mostly single line changes sprinkled throughout the source.
However there are some fractint features that are so closely coupled to video that they might pose a problem (e.g. orbits or inverse julia windows).
I'd have to double check the source to be sure, but I painstakingly studied every single piece of fractint source that did any video I/O. It all goes through a set of functions which in the DOS port are coded in assembly. That's how xfractint managed to get things ported to X11 -- they replaced all those assembly functions with C versions that did something X-ish. What I did was the same thing, just pushing it a little farther so that instead of calling a function directly, they call the function through a pointer to a struct containing function pointers, with the struct pointer being a global for the "current driver".
This at least gets you to the point where you could switch drivers on the fly.
I recall a story a while ago about an opinion of a fairly iconoclastic software mover and shaker (wish I could remember who it was) who said that legacy code should be treated with respect. It represents uncounted hours of development and debugging, and when people see its defects and bravely sugeest total rewrites, the effort is almost always under-estimated. The whole refinement effort has to be redone.
I totally agree with this sentiment, which is why I started that driver layer effort by studying the source code intensively. Its a huge pile of printout! However, doing this made me appreciate the size of the task and the necessity for "going slow, one step at a time" on the way towards a reincarnated fractint that behaved like a native application on window systems and like the traditional fractint on a DPMI DOS port.
On the other hand, whenever code is touched that area of code can be refactored. And one can make architectural changes - I've done it with fractint several times myself :-)
Refactoring is good! -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
I agree with Rich, and I am willing to put some energy in it as well... OT, but oh well... I can't remember how old I was, but it was at the time where a 286 (IBM Z50) was really fast - my dad brought home a BASIC source that would calc the mandelbrot. It took the whole night to render it... Ever since, I've been fascinated by computer graphics and fractals. My first book I got on graphics is dated '85 (age 13), and - guess what - I just found a book sitting on my shelf: 'Image Lab' by ... Tim Wegner! ;) (must have been '95 when I got it). Guess what I'm doing today... :) http://www.in-gmbh.de/en/Products/in-gmbh/sphinxsvg/svg_demos.htm Cheers, Florian
[mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Rich
While I didn't want to rewrite the code base (I'm not -that- much of a masochist! :-), I did make a fairly extensive change with the driver layer :)
participants (3)
-
Florian Kolbe -
Rich -
Tim Wegner