Good points about everything, I was going to comment that we could develop our own (but it would take a long time - though I think not as long as you stated), but you covered that too.
CVS it is. Joseph Carter wrote: > I've been giving some thought to VCS lately. I have no happy news to > report I'm afraid. I've looked at several that I know of, trying to > decide which of them is the best of those which are available, etc. Let > me first say that perforce and bitkeeper began in this comparison with > about two and a half strikes against them because of their non-free > nature. Neither managed to so completely and overwhelmingly impress me > that I was able to look beyond that fatal aspect. > > > The other contenders: > > Subversion > > I must say that I really wanted to like subversion. It has traces of > CVS in its design because it's developed by people who worked on CVS. > It seems like it would be the least of a paradigm shift for us to adopt, > though we'd probably have to relearn several things anyway. > > Subversion is not without its failings though. First, it depends on > Apache 2. We're using Apache anyway, but Apache 2 isn't out yet. While > I have installed sid on vickery, I have done so only because I cannot > with clear mind install potato on any machine, and because most of us > are pretty well familiar with Debian sid. > > Currently with CVS, everyone is making their commits to trunk. This > does seem in the short run to be simpler, but in the long run it is > clear that lack of branched development is slowing down the project as a > whole. The best way to handle this is probably to limit commits to > trunk to a few people and have the larger group work out of branches. > Subversion does not allow this to be done as a matter of policy. I > think each of us who has ever worked with branches in CVS has made the > mistake at least once and committed something intended for a branch to > the trunk. It's a very common mistake for people who have not worked > with CVS branching much. > > And despite CVSgui (WinCVS) being best described by all as a smelly > flaming turd, it is far more convenient for win32 users than opening up > a dos box for command line CVS. MacOS Classic users don't even have > that option, they must use CVSgui. Subversion is command line only at > this time, making it a great burden for our win32 developers, and if we > plan to support MacOS Classic in the future, we can't use it. > > > arch > > I wanted to like arch even more than Subversion. It was designed to > make itself work with your existing development tools, particularly with > grep and diff for people with unix-style environments at their disposal. > It was also designed to maintain local copies of revision histories and > the like, so that you are not crippled if something happens to the main > server. An arch repository is as easy to mirror as an ftp mirror and > you are able to have and use more than one repository for a project with > many branches each. > > The author of arch is very proud of his decentralized approach, and with > good reason. It truly does allow for several branches to be used, as > well as many servers. It is reasonably simple to set up local > repositories in which you can have changes that don't work yet (we all > know that committing stuff that doesn't work yet is a good way to get a > lot of people rather annoyed rather quickly..) and you can later merge > those changes, with history, with anyone else's servers before even > getting near the trunk. He is also proud that unlike Subversion, arch > does not depend on a bunch of untrusted, unreleased tools. > > Unfortunately, his avoidance of dependencies is where arch falls short > of our needs. While arch comes with tools for the kind of web interface > we get with ViewCVS, its remote server mechanism is ftp. I don't like > or trust ftp, it's a glaring security risk. Secure ftp is nice where it > is supported, but it's not supported everywhere. Also, subversion was > developed with portability to unix systems in mind, not anywhere else. > Not only does it only provide command line tools, they are written in > sh, sed, and awk! Win32 support is possible, probably only with cygwin > though, since I happen to know how poorly those tools have been ported > by others to make win32 feel unixy. MacOS Classic? Forget it. > > As cool as arch is, without a C implementation and perhaps some https > server implementation, I'm somewhat reluctant to even consider it for > our work. I'm sure it could probably be ported to C with libpcre. It > could certainly be implemented in perl, but perl is only marginally more > useful on our non-POSIX platforms than sh/sed/awk are. We're also in a > bit of a hurry. > > > CVS > > We all know CVS at least a little. It's by far the most portable, and > likely also the most annoying. Diffs are a requirement for anyone > without write access to the trunk because they cannot make and store > local branches and revisions. If the central server goes down, all of > us are stalled until it comes back up again. Mirroring a repository is > possible if the repository is made mirrorable, but once mirrored it is > difficult to merge changes back in. It requires direct repository > access to move files or directories, and then it doesn't work smoothly. > > Many people have tried to replace CVS. Some of the most successful > attempts are non-free. Others are not portable or not mature, But in > large, CVS remains the dominant version control system because despite > all its faults, it is the most widely supported, most portable, and most > understood tool out there. Someday subversion may change that. In unix > circles, arch may as well. But for now, love it or hate it (and most of > us DO hate it), CVS is still the only tool that we can really use. > > > I'd appreciate comments, and if someone wants to forward my comments to > the makers and maintainers of these and other VCS projects. It'd take us > months of development to replace CVS with something more suited to our > needs, and then twice as long again to make it usable on those gooeys like > win32 and Mac classic, and longer still to test everything to an extent > that we'd dare trust our code to it. That's a lot of time we just don't > have, and for the most part our team's experties lies in solving other > kinds of problems anyway. > > We must, unfortunately, leave developing the next generation version > control system in the hands of those who have the skill and desire to work > in that field, and just have to hope that solutions they find will work > for us. > > -- LordHavoc Senior Editor for http://www.gamevisions.com A member of the Brotherhood of The Axe game clan. Author of DarkPlaces Quake1 engine and mod ( http://darkplaces.gamevisions.com/ ) "War does not prove who is right, it proves who is left." - Unknown _______________________________________________ twilight-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/twilight-devel
