Working in FractInt really makes me miss objects. C++ is backwards compatible with C as long as you avoid variables called 'new' and so-on. I've already refactored the identifiers that conflict with C++ keywords not present in C. So what I'm thinking is that I'll just take all the *.c files on the branch and save them as *.cpp. Then address any compile errors or warnings that might result. It will still be a gigantic 1990-style C program, but now when we add new code we can add it as objects. Existing code can be incrementally refactored(*) into objects. This is the approach I intend to take on the source. It won't happen overnight. But slowly, gradually, the code will move to objects and interfaces with locally encapsulated state that will allow the engine to be repurposed in many, many ways... I don't care so much if the DOS UI dies, but I want to see the parameter file stuff, the formula stuff and the fractal types live on (and probably some other stuff too, but I'm not trying to make an exhaustive list here). Any thoughts are welcome... (*) I should be specific with the word "refactor" here as it can have just the English language intuitive meaning of re+factor, but in software engineering it means something specific. A refactoring is a change to the structure of the code that preserves the behavior of the code to all callers (implementation may change, but behavior is preserved). For examples of specific code transformations that are considered refactorings, take a look at <http://www.refactoring.com/> and browse the "Catalog" link at the top of the page. So how do you know if the behavior has been preserved across the change? Unit tests. That might sound like a bunch of extra work, but reading the book "Working Effectively with Legacy Code" by Michael Feathers has convinced me it can be done to an existing body of code like FractInt in an incremental fashion. <http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/> <http://www.objectmentor.com/resources/books.html> -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich wrote:
So what I'm thinking is that I'll just take all the *.c files on the branch and save them as *.cpp. Then address any compile errors or warnings that might result. It will still be a gigantic 1990-style C program, but now when we add new code we can add it as objects. Existing code can be incrementally refactored(*) into objects.
I don't have a problem with this strategy but I do have a question about timing. How far along are we on getting the entire feature set working? Should we get it to releasable form and then move the language? A related question might be, what is the speed relative to the DOS version? Do we need a step of optimizing some of the bottlenecks? Perhaps it's not a question of one or another, maybe these are two independent efforts. I realize that you are proposing incremental refactoring, so maybe timing is not an issue. On a tangential note, after bravely predicting my availability in February, I realized too late that it's not just the disruption of redoing one's house that takes up time, but also moving back in when the project is "done". Be that as it may, I'm ready to begin looking at this project more closely. Life is much simpler now that we are not camping out in our own house. My computer room is still a bit of a mess, but then I am perpetually organizing it :-) Should I start with the 2003 compiler you sent or get the 2005 version? I saw your note a few days ago about maintaining two project files. Since I haven't invested any time getting set up yet (other than keeping current with CVS), let me know if it matters which compiler I start with. On a third topic, would you be open to migrating to Subversion, or would you rather stick with CVS? As you probably know, while SVN aims to be a better CVS, it is significantly better in a number of ways. Two that come to mind are versioning directories and supporting renaming, and the fact that it doesn't version individual files but rather versions the whole project. This latter takes getting used to since changing any file bumps the version up, but in many cases this is what we want, since it automatically tells you which file revisions correspond to a particular patchlevel without any special tagging. I only suggest this only because I am using subversion at work and I'd prefer to learn one system well, and subversion does seem to be becoming more of a standard. However since you are doing the lion's share of the work, if you don't like this idea we can stick with CVS. I would understand the argument that CVS meets our needs, and migrating would just distract us from the task at hand. Having said that, and having used both CVS and SVN, I'd have to say SVN is a serious upgrade that might have productivity benefits down the road. Tim
In article <461423F9.14817.AFB62D@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
I don't have a problem with this strategy but I do have a question about timing. How far along are we on getting the entire feature set working?
On the Windows side, with Jonathan's addition of the mouse support, I believe we're as feature complete as we can be without converting more assembly language to C or 32-bit assembly. The X11 path is lagging and needs some driver implementation before it will be working. I make sure that it compiles, but I haven't been keeping the X11 driver working. One reason is that I don't really have an X11 development environment setup right now and another is that as I progress through the Windows issues, I occasionally need to add a new driver method. My plan was to release for Windows in both binary and source form. Then work on the X11 driver and do an X11 release in binary and updated source.
Should we get it to releasable form and then move the language?
Considering that we release binaries and sources, I want to move everything to .cpp before releasing the source. Honestly, I don't expect renaming the files to introduce any functional issues. Maybe a few compiler warnings at this point, but considering I've already renamed all the variables that are keywords in C++ but not in C, I don't expect any actual compile errors.
A related question might be, what is the speed relative to the DOS version?
I recall getting a message from Lee Skinner (I think it was Lee) who did some comparison timings on an earlier beta and he said the Windows version was faster. This is not surprising since you're no longer using the 16-bit instruction set, which is a slower path on modern CPUs.
Do we need a step of optimizing some of the bottlenecks?
Aside from the update rate, which I capped at 10fps in the most recent beta, there haven't been any comments about speed or performance.
Should I start with the 2003 compiler you sent or get the 2005 version?
I would go with the 2005 Express Edition. However, you'll need to download and install the Platform SDK in addition to the Express Edition to get FractInt for Windows to compile (or any Windows program, for that matter). You might want to keep 2003 around if you need to compile any MFC code. MFC and ATL libraries are not included in the Express Edition. You can compile code to the Win32 API once you install the Platform SDK which gets you headers and libraries for the Win32 API. Without the Platform SDK you have an ANSI/ISO C++ compiler, but not enough to compile to the Win32 API.
On a third topic, would you be open to migrating to Subversion, or would you rather stick with CVS?
If we migrate to subversion before I move *.c to *.cpp, then the version history of the .c file will tag along with the renamed .cpp file. This would be very helpful!
Two that come to mind are versioning directories and supporting renaming, and the fact that it doesn't version individual files but rather versions the whole project. [...]
I didn't know that about the versioning but I'm OK with that.
I only suggest this only because I am using subversion at work and I'd prefer to learn one system well, and subversion does seem to be becoming more of a standard. However since you are doing the lion's share of the work, if you don't like this idea we can stick with CVS.
I like the idea of switching before I rename the files so that the version history is kept intact.
I would understand the argument that CVS meets our needs, and migrating would just distract us from the task at hand. Having said that, and having used both CVS and SVN, I'd have to say SVN is a serious upgrade that might have productivity benefits down the road.
Its my understanding that there's a tool you run on your CVS Repository to turn it into an SVN store (whatever they call it), so it sounds pretty painless. Its not like we'd be bleeding edge in this regard, I think a lot of people have converted CVS stores to SVN stores. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
I would understand the argument that CVS meets our needs, and migrating would just distract us from the task at hand. Having said that, and having used both CVS and SVN, I'd have to say SVN is a serious upgrade that might have productivity benefits down the road.
Its my understanding that there's a tool you run on your CVS Repository to turn it into an SVN store (whatever they call it), so it sounds pretty painless. Its not like we'd be bleeding edge in this regard, I think a lot of people have converted CVS stores to SVN stores.
I have tried to use at least two different conversion tools, with no success. Don't recall which ones. Our CVS source tree is pretty ugly, so I wasn't surprised. Jonathan
Jonathan wrote:
I have tried to use at least two different conversion tools, with no success. Don't recall which ones. Our CVS source tree is pretty ugly, so I wasn't surprised.
There's more than one approach we could take. We could just start fresh with subversion and check in current sources, and keep the old change history in CVS. Or we could create several (as many as needed) incremental versions from CVS and check them in successively to SVN. Or we could write a script that would grab versions from CVS and commit to SVN. We don't have to get the structure perfect before we start, because once in subversion, you can rename files and directories and move things without destroying history. Tim
In article <46161659.6902.5255B2@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Jonathan wrote:
I have tried to use at least two different conversion tools, with no success. Don't recall which ones. Our CVS source tree is pretty ugly, so I wasn't surprised.
There's more than one approach we could take. [...]
Why don't we just try one of the Repository conversion scripts/tools and see how it goes? No harm will be done to the original Repository if it doesn't work. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich wrote:
Why don't we just try one of the Repository conversion scripts/tools and see how it goes? No harm will be done to the original Repository if it doesn't work.
I am looking into this. I have copied cvs2svn into my account and am experimenting. This will delay my getting the compiler installed, but this is probably a better way for me to help at the moment. Tim
Oh Dear, Just when I'm getting my head around CVS, we are now going to SVN. I am beginning to feel like a real dummy here. May I be so bold as to ask what SVN is? Thanks guys... Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com] On Behalf Of Tim Wegner Sent: Saturday, 7 April 2007 3:10 AM To: Fractint developer's list Subject: [Fractdev] Subversion migration Rich wrote:
Why don't we just try one of the Repository conversion scripts/tools and see how it goes? No harm will be done to the original Repository if it doesn't work.
I am looking into this. I have copied cvs2svn into my account and am experimenting. This will delay my getting the compiler installed, but this is probably a better way for me to help at the moment. Tim _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <E1HZtsh-0006Bw-5d@pecan.exetel.com.au>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Just when I'm getting my head around CVS, we are now going to SVN. I am beginning to feel like a real dummy here. May I be so bold as to ask what SVN is?
SVN is SubVersion, a followon source control system to CVS. I don't expect from your point of view things will change much. There's a Toirtoise client for it too. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Thanks Richard :o) ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Richard Sent: Saturday, 7 April 2007 5:31 AM To: Fractint developer's list Subject: Re: [Fractdev] Subversion migration In article <E1HZtsh-0006Bw-5d@pecan.exetel.com.au>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Just when I'm getting my head around CVS, we are now going to SVN. I am beginning to feel like a real dummy here. May I be so bold as to ask what SVN is?
SVN is SubVersion, a followon source control system to CVS. I don't expect from your point of view things will change much. There's a Toirtoise client for it too. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Paul wrote:
Just when I'm getting my head around CVS, we are now going to SVN. > I am beginning to feel like a real dummy here. May I be so bold as to ask what SVN is?
As Richard said, changing from CVS to SVN won't affect you much at all. You need about two commands. Which brings me to: the instructions I gave you were just to get started. Once you have a working copy, you just need the update command. If you have questions, send me what you are up to off list. Tim
In article <46166601.26805.1897E50@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
[...] Once you have a working copy, you just need the update command.
There have been a lot of updates lately... -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Tim, I logged into bazooka, copied cvs2svn and fractcvs to my home directory on bazooka and ran it against the repository and no errors were reported. I will install TortoiseSVN and send another email when its a good time to convert the repository. We probably want this last DOS release to happen from CVS and then convert... I'm in no rush to do the subversion migration, except that I'd like to do it before the "save .c as .cpp" change. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich wrote:
I logged into bazooka, copied cvs2svn and fractcvs to my home directory on bazooka and ran it against the repository and no errors were reported. I will install TortoiseSVN and send another email when its a good time to convert the repository. We probably want this last DOS release to happen from CVS and then convert... I'm in no rush to do the subversion migration, except that I'd like to do it before the "save .c as .cpp" change.
Thanks for taking the initiative, I'll have a look. Your timing sounds fine with me. Beware, though, the seemingly simple steps to release always take longer than one might think, and that's when we've been more active - and this time it's been quite a while. At the moment we can use subversion the same way we use CVS, in file mode, but I can set up a server version with a web interface for copying out code. Tim
In article <461BCC38.16463.1B4E0D@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
At the moment we can use subversion the same way we use CVS, in file mode, but I can set up a server version with a web interface for copying out code.
I'm not quite sure what you're saying here. There's no point in going to subversion while the CVS repository is still in use. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
I'm not quite sure what you're saying here.
There's no point in going to subversion while the CVS repository is still in use.
Agreed, I was not talking about using CVS and SVN together, but was referring to the fact that SVN can be used in file mode (usually when the repository is on the same file system as the the user), or as a server. I *believe* Tortoise uses the file mode. I am going to try to duplicate your results with cvs2svn and experiment before we do this for real. Tim
In article <461C0CBC.14985.1174FC8@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Agreed, I was not talking about using CVS and SVN together, but was referring to the fact that SVN can be used in file mode (usually when the repository is on the same file system as the the user), or as a server. I *believe* Tortoise uses the file mode.
I think its all irrelevant to the clients. That's all an implementation detail on the server side (Berkeley DB or file). I think the one I did was Berkeley DB and the manual I printed out indicated that it was the more stable version.
I am going to try to duplicate your results with cvs2svn and experiment before we do this for real.
Yep. I was thinking that as long as we have no outstanding commits we could change to subversion at any time. If the next release is going to be a while coming, then I would rather do that. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich, - I think its all irrelevant to the clients. That's all an - implementation detail on the server side (Berkeley DB or file). I don't think Tim was referring to the repository storage method (bdb or fsfs) but rather the way in which users check in code. With CVS each file is checked in (there are no atomic multi-file commits) and you can just use Subversion like this too. Later, as you become more comfortable with Subversion, you can try committing multiple files at once... and it just works. There's also the issue of how access to the repository itself is granted. If you're on the same host as the repository, you can access it via file:// URLs, and the client programs simply use local filesystem calls (this is the ra_local module). If you're not on the same host, or are but want to isolate yourself from the repository for some reason, you can use svnserve to provide access via svn:// URLs (ra_svn module) or use Apache and DAV to provide access via http:// URLs (ra_dav module). The storage mechanism used is largely a matter of personal taste. In my opinion, the fsfs storage is just fine; there's less (zero) possibility of the repository becoming "wedged", and you can always get a consistent repository snapshot without extra processes, which is great for backups. A run-down of the differences can be found here: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.repo sadmin.basics.backends Note that as of Subversion 1.2, fsfs is the default, even though they explicitly state neither is more official than the other. Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/
In article <200704111819000484.1ED9CCBB@mandy.fractalus.com>, "Damien M. Jones" <dmj@fractalus.com> writes:
I don't think Tim was referring to the repository storage method (bdb or fsfs) but rather the way in which users check in code. With CVS each file is checked in (there are no atomic multi-file commits) and you can just use Subversion like this too. Later, as you become more comfortable with Subversion, you can try committing multiple files at once... and it just works.
I commit multiple files at once with TortoiseCVS all the time. Of course the log message is just duplicated for each file, unlike the way SVN tracks groups of files as a single change. In reading through the SubVersion manual, it doesn't seem any different than CVS from a user's perspective, except in the way that version numbers are assigned.
There's also the issue of how access to the repository itself is granted. [...]
I was guessing we'd use svn+ssh://bazooka.dreamhost.com/users/twegner/fractint/fractsvn/ as the base URL for the SVN repository.
Note that as of Subversion 1.2, fsfs is the default, even though they explicitly state neither is more official than the other.
Ah, OK, I guess the manual is a little out of date then. The manual says that the BDB one is the default and the flat-file repository organization is there, but a little untested. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Richard, - I commit multiple files at once with TortoiseCVS all the time. Yes, but they're separate commits. If someone else is getting files from CVS while you're committing changes, they may get an incomplete change--some files from before your commit, some files from after. With Subversion, this can't happen; each commit--no matter how many files--is atomic. And they're automatically grouped together, rather than a series of several (hopefully related) commits. I have used this to successfully commit thousands of files at once. - In reading through the SubVersion manual, it doesn't seem any - different than CVS from a user's perspective, except in the way - that version numbers are assigned. Mostly that is true, especially since that was a primary design goal of Subversion. - I was guessing we'd use - - svn+ssh://bazooka.dreamhost.com/users/twegner/fractint/fractsvn/ - - as the base URL for the SVN repository. According to the documentation, this is the svnserve process using an SSH-encrypted tunnel. This is not the same thing as local file access, since it requires the svnserve process to be set up. (I've never set one of these up; so far, I've always used either file:// URLs or DAV.) - Ah, OK, I guess the manual is a little out of date then. Not necessarily. The latest Subversion is 1.4.3 (which has a weird incompatibility with Apache 2.2.4 and DAV over SSL with client certificates and CNs as usernames; 1.4.2 doesn't have this problem, and neither does Apache 2.0.59). What I have noticed is that many pre-packaged distributions (Debian stable, Red Hat Enterprise Linux, I'm talking about you) still come with much older versions of Subversion, 1.1.x or 1.2.x. These versions will still work just fine, but 1.4.x offers substantial performance improvements. Compiling a custom Subversion package is a pain, however, as there are lots of library dependencies with their own sets of dependencies. Tim, - For the record, that was indeed what I meant. That is, you meant accessing the repository through the local filesystem (file:// URLs), not necessarily using the fsfs back-end repository storage, which is largely transparent to the way you actually use the repository. What I've noticed when running Subversion with local repositories is that regardless of the back-end storage, Subversion expects that you have access to the repository files, and doesn't deal with things well if you don't. So you could set up a group, assign developers to it, and then create the repository owned by the group... but if *anything* lacks group write access, Subversion can choke. One wrong umask and you've got to fix it. I solved this by wrapping the svn binaries with simple scripts that force the umask to something sane, then invoke svn as before. The repository then gets set up with group write access as it should, but the rest of my files can keep their group-not-writable setting. I can explain more if you like; the docs are... muddy about this. Since I've been using Subversion through a command line I've not had a pressing need to set up TortoiseSVN. It's on my list of things to do. - At work we use the fsfs system and it works great. In studying - the documentation I couldn't see any advantage to bdb. One major advantage: if you frequently do very large commits over a network with a very short idle timeout (e.g. through a NAT box), you can get timeouts with fsfs at the end of the commit as the data transfer happens at the beginning of the transaction and then the connection is silent for a long time. (Yes, I've done this.) With BDB it spreads out the data transfer more evenly and timeouts don't happen. Other than that, fsfs is more flexible all around. That particular choice isn't even that critical; to change formats, one simply dumps the repository to a portable format, recreates it with the new storage type, and re-imports from the dump. As easy as 3.1415926353897932384626433832795... Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/
In article <200704112112580078.1F791094@mandy.fractalus.com>, "Damien M. Jones" <dmj@fractalus.com> writes:
According to the documentation, this is the svnserve process using an SSH-encrypted tunnel. This is not the same thing as local file access, since it requires the svnserve process to be set up. (I've never set one of these up; so far, I've always used either file:// URLs or DAV.)
For what its worth, it works on bazooka. I made a repository from the CVS repository, checked it out on xmission's shell (with svn version 1.1.4), made some modifications and checked them back into my repository on bazooka (which has svn version 1.3.2). I used svn+ssh://bazooka.dreamhost.com/.... for the URL without any problems. I didn't have to set anything up on the bazooka site, but obviously they already have subversion installed since I didn't have to build subversion.
That is, you meant accessing the repository through the local filesystem (file:// URLs), [...]
I just don't see how this (file:// URLs) could possibly work given that the repository is *not* local, its on bazooka. Am I missing something or are you just talking about some other scenario and not what we would do for fractint? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich, - I just don't see how this (file:// URLs) could possibly work - given that the repository is *not* local, its on bazooka. Am - I missing something or are you just talking about some other - scenario and not what we would do for fractint? Tim mentioned file mode, which would work using file:// URLs if you were working by logging into bazooka. But you don't actually do your work on bazooka, so he was talking about using it via svn+ssh, which as he indicates in the docs works with very similar access controls as file URLs. I suspect the documentation that says svn+ssh is like svn but wrapped in ssh is wrong; that it is, in fact, like a local command line (not using svnserve) and the ssh just means to remotely log in and issue the commands. So what I said earlier about svn+ssh requiring the svnserve process is, I think, wrong. I was not necessarily speaking just about FractInt development--I was trying to share some of my other experiences with Subversion and the many different ways it can be set up. The permission issue is real. What it means is that everyone who has access to the repository has complete, unfettered access; you can commit anywhere in the source tree; you can destroy the entire repository. I doubt that's a problem for the FractInt team, since the odds of having a rogue developer are fairly small. In larger projects it does become an issue, and more complicated setups involving DAV allow you to restrict individual users to particular portions of the directory tree. Using DAV or svnserve also isolates developers from having direct access to the repository directory; they must work through Subversion to make changes. I honestly think that svn+ssh, as you've tested it, will be the best approach for FractInt. You still control access (by granting access to bazooka and including people in the group necessary to access the repository) but you get to use easy setup. Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/
Damien, Would the svn+ssh mode that you recommend still allow you to provide 'read only' access to those who you might want to let look at code, but not check it back in? I ask because of your statement:
The permission issue is real. What it means is that everyone who has access to the repository has complete, unfettered access; you can commit anywhere in the source tree; you can destroy the entire repository.
- Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
-----Original Message----- From: fractdev-bounces+hallane=earthlink.net@mailman.xmission.com [mailto:fractdev-bounces+hallane=earthlink.net@mailman.xmission.com ]On Behalf Of Damien M. Jones Sent: Thursday, April 12, 2007 8:02 AM To: Fractint developer's list Subject: Re: [Fractdev] Subversion migration
Rich,
- I just don't see how this (file:// URLs) could possibly work - given that the repository is *not* local, its on bazooka. Am - I missing something or are you just talking about some other - scenario and not what we would do for fractint?
Tim mentioned file mode, which would work using file:// URLs if you were working by logging into bazooka. But you don't actually do your work on bazooka, so he was talking about using it via svn+ssh, which as he indicates in the docs works with very similar access controls as file URLs. I suspect the documentation that says svn+ssh is like svn but wrapped in ssh is wrong; that it is, in fact, like a local command line (not using svnserve) and the ssh just means to remotely log in and issue the commands. So what I said earlier about svn+ssh requiring the svnserve process is, I think, wrong.
I was not necessarily speaking just about FractInt development--I was trying to share some of my other experiences with Subversion and the many different ways it can be set up.
The permission issue is real. What it means is that everyone who has access to the repository has complete, unfettered access; you can commit anywhere in the source tree; you can destroy the entire repository. I doubt that's a problem for the FractInt team, since the odds of having a rogue developer are fairly small. In larger projects it does become an issue, and more complicated setups involving DAV allow you to restrict individual users to particular portions of the directory tree. Using DAV or svnserve also isolates developers from having direct access to the repository directory; they must work through Subversion to make changes.
I honestly think that svn+ssh, as you've tested it, will be the best approach for FractInt. You still control access (by granting access to bazooka and including people in the group necessary to access the repository) but you get to use easy setup.
Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/ _______________________________________________
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.2.0/757 - Release Date: 4/11/07 5:14 PM
In article <MDBBJLBFBICIIEIHFBMEEELKDAAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
Damien, Would the svn+ssh mode that you recommend still allow you to provide 'read only' access to those who you might want to let look at code, but not check it back in?
It might be easier to check out the source into a web browseable directory. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich, - It might be easier to check out the source into a web browseable - directory. And in fact you can automate this with a post-commit hook script. I've done this in a couple of installations and it works fairly well. - I suppose you could look at some way of setting up DAV access to - bazooka, but that would probably require dreamhost.com to get - involved... Yes, it would; it gets very messy because you have to tweak the web server configuration in ways that can compromise its security if you get it wrong. Setting up DAV access in general is much more complicated than svnserve because configuring Apache is a non-trivial task. Very doable (I can't count how many times I've done it) but not for the faint of heart or those who think they can spend ten minutes on the job and be done. If you do set up DAV access, you can actually give out full read access to the entire revision tree (via DAV+DeltaV) so that ordinary web clients can read the current version, and DeltaV clients like TortoiseSVN or the Subversion command-line tools can read all versions. If this weren't tax weekend I'd probably be offering a lot more help with this. :-) Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/
Hal asked:
Would the svn+ssh mode that you recommend still allow you to provide 'read only' access to those who you might want to let look at code, but not check it back in?
We *will* be able to provide this kind of read-only web access, not to worry. But Damien's suggestion of providing web access to a checked-out version is also very easy to do, though this strategy does not let you access anything but the current version. Tim
In article <200704120801590734.21CB446D@mandy.fractalus.com>, "Damien M. Jones" <dmj@fractalus.com> writes:
The permission issue is real. [...]
OK, thanks for explaining that. I suppose you could look at some way of setting up DAV access to bazooka, but that would probably require dreamhost.com to get involved and potentially more fees.
I honestly think that svn+ssh, as you've tested it, will be the best approach for FractInt. You still control access (by granting access to bazooka and including people in the group necessary to access the repository) but you get to use easy setup.
It worked when I tried it on xmission's shell using ssh-agent, but when I tried it on my laptop with ToirtoiseSVN and pageant, it kept prompting me for a password. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Damien wrote:
I don't think Tim was referring to the repository storage method (bdb or fsfs) but rather the way in which users check in code.
For the record, that was indeed what I meant. At work we use Linux with a shared NFS file system. Anyone can then use SVN to create a repository anywhere in the file system and administer it themselves. This is what I call "file mode". You check in and check out just using the svn program. In this mode the only way I see to control access is with file permissions. (This is discussed in the SVN docs but is confusing). Both our CVS repositories (fractint.org and fractint.net) work this way, using group write permission. There is a separate program (that I have no experience with) that sets up a SVN server that is centrally administered, and assumes network access. It is this distinction that I was discussing. The fractint.net host appears to offer a means of setting up the client- server system. However, if we are using tortoise to access subversion, then I believe we don't need the server.
The storage mechanism used is largely a matter of personal taste. In my opinion, the fsfs storage is just fine; there's less (zero) possibility of the repository becoming "wedged", and you can always get a consistent repository snapshot without extra processes, which is great for backups. A run-down of the differences can be found here:
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.repo sadmin.basics.backends
At work we use the fsfs system and it works great. In studying the documentation I couldn't see any advantage to bdb. Tim
In article <461D33E5.2864.87497B@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
For the record, that was indeed what I meant. At work we use Linux with a shared NFS file system. Anyone can then use SVN to create a repository anywhere in the file system and administer it themselves.
OK, it seems we are talking about two things as if they are one. First, from what I read of SVN, anyone can make any directory tree they want anywhere they want. The "repository" is just the root directory under which they create their stuff. If your repository is sitting on an NFS mount point, then yeah, to you it looks like a local file repository. However, I don't think we intend to use bazooka.dreamhost.com's SVN repository as an NFS mount point. Instead, I was expecting that we'd use SSH tunnelling to talk to bazooka.
This is what I call "file mode". You check in and check out just using the svn program.
Same for SSH tunnelling.
In this mode the only way I see to control access is with file permissions. (This is discussed in the SVN docs but is confusing). Both our CVS repositories (fractint.org and fractint.net) work this way, using group write permission.
Same for SSH tunnelling. To SVN it looks like you are a local user executing svn commands on bazooka, but you're really using SSH to tunnel through the internet and have the command executed there on your behalf and the results sent through the SSH connection back to your local machine.
There is a separate program (that I have no experience with) that sets up a SVN server that is centrally administered, and assumes network access.
With SSH tunneling, we don't need this. This is the equivalent of cvsd, which we don't use either.
At work we use the fsfs system and it works great. In studying the documentation I couldn't see any advantage to bdb.
OK, I don't recall where I saw this in the 'book' (which is not to say that its in the documentation man pages or whatever). I downloaded a fat PDF file containing a book on SubVersion; that's what I was looking at. Let me try an SSH tunnelling experiment on bazooka and see if I can get the source and make simple modifications and commit them. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Chapter 6 of the Subversion Book (http://svnbook.red-bean.com/nightly/en/svn- book.html#svn.serverconfig) deals with the server. I found this paragraph: "Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file- permissions problems (see the section called "Supporting Multiple Repository Access Methods".) Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs - from a security standpoint, it's effectively the same as local users accessing via file://, and can entail all the same problems if the administrator isn't careful." Let me say I am not advocating using the server, just trying to better understand. I *have* experienced the permission issues they mention, but I can't say the permission vulnerabilities have caused a problem with the small trusted teams I work with at work, nor would I have a problem using this mode with our small team here. Having said that, I'll look into setting up the server mode. The one thing that might give us read-only web access which might be useful. Tim
On Thu, 2007-04-05 at 09:49 -0600, Richard wrote:
On the Windows side, with Jonathan's addition of the mouse support, I believe we're as feature complete as we can be without converting more assembly language to C or 32-bit assembly. The X11 path is lagging and needs some driver implementation before it will be working. I make sure that it compiles, but I haven't been keeping the X11 driver working. One reason is that I don't really have an X11 development environment setup right now and another is that as I progress through the Windows issues, I occasionally need to add a new driver method. My plan was to release for Windows in both binary and source form. Then work on the X11 driver and do an X11 release in binary and updated source.
The mouse support isn't quite right, yet. It would be impossible to use in a full screen mode. I would first like to release a DOS version 20.5. Just to wrap it up in one final official release. Jonathan
In article <1175822280.3918.8.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
I would first like to release a DOS version 20.5. Just to wrap it up in one final official release.
I like that idea. I've been tracking changes on the HEAD and merging them into the branch. Has there been anything lately, since history.c was created? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
On Thu, 2007-04-05 at 23:06 -0600, Richard wrote:
I like that idea. I've been tracking changes on the HEAD and merging them into the branch. Has there been anything lately, since history.c was created?
I think the last change I made was to miscovl.c to turn off adding the patch information to PARs, except when debugflag!=0. Although, it is interesting to see who is using Fractint for Windows. Jonathan
participants (6)
-
Damien M. Jones -
Hal Lane -
Jonathan Osuch -
Paul -
Richard -
Tim Wegner