Multi-User Subversion 159
chromatic writes "Rafael Garcia-Suarez has just penned an article about adopting Subversion for multi-user projects. (He also has a previous article on Single-User Subversion). With the recent release of Subversion 0.16 (see the File sharing link), the successor to CVS looks very good."
Subversion vs CVS (Score:3, Insightful)
Whats the advantage to killing the standard of CVS, that seems to work well today? I mean, are the features of this "Subversion" make it worth the switchover?
Re:Subversion vs CVS-Alternatives? (Score:1, Interesting)
Re:Subversion vs CVS (Score:2, Funny)
obKarmaWhoring: http://subversion.tigris.org/
Re:Subversion vs CVS (Score:5, Informative)
On the flip side, I do not suggest using Subversion for any critical project at this point since they are not feature complete for their first release and their bug list, frankly, scares me.
CVS still awfully nice (Score:4, Informative)
Yeah, there are probably things about CVS that could be better. But if you've never used it, and aren't already using a competitor, it's really good.
Re:CVS still awfully nice (Score:4, Informative)
Public service announcement
If you're in windows and trying CVS, check out tortoise [sourceforge.net]
Re:CVS still awfully nice (Score:3, Funny)
On a project with more than two developers, quitting to work the fryer at McDonald's is way better than no version control.
Re:CVS still awfully nice (Score:3, Funny)
That's what middle-school geeks used to say about BASIC.
Re:Subversion vs CVS (Score:1)
Re:Subversion vs CVS (Score:5, Interesting)
Briefly, CVS lacks version control across file renames, has some issues with binary files, and the CVS code base has serious design issues.
Re:Subversion vs CVS (Score:2, Informative)
Version control works fine across file renames; CVS simply doesn't make it obvious that a rename happened (the old file disappears, a new file with a clean log appears). The simple way of dealing with it is to add a comment to the new file "formerly known as".
If it really confuses you, it's easy to give people a shell script to do the remove/add, add a comment, and optionally, add a copy of the old log. Perhaps the CVS developers should do just that.
has some issues with binary files,
I dunno--they seem to get handled just fine. They aren't diffed, but so what? Perhaps the CVS frontend should finally detect binary files automatically--doing that wouldn't be hard.
the CVS code base has serious design issues.
Lots of widely used big C programs have "serious design issues", at least in some people's eyes. I've come to the conclusion that if it works reliably, it's best not to look under the hood. And CVS works reliably. I'd trust it over a well-designed but new codebase any day.
Re:Subversion vs CVS (Score:4, Informative)
Re:Subversion vs CVS (Score:5, Informative)
Directory handling springs to mind, as does renaming files. Atomic commits too. As well, there's also the fact that you often end up editing the modules files directly - an end-user should never have to care about a program's internal storage of meta-data.
Now, I haven't used Subversion so I am unable to make a comparison. I understand it handles directory versioning better, but I'm not aware of the rest of the points I made. The directory handling alone is a huge plus however, so it's a project whose announcements I'm following closely.
Cheers,
Ian
Re:Subversion vs CVS (Score:1, Funny)
I have that trouble all the time.
Fortunately, you can get a quick reminder here...
http://developers.slashdot.org/comments.pl?sid=
Listing of all known SCM software for Linux (Score:2)
Subversion is indeed already a giant step better than CVS in all the areas where CVS was painful, while having a good migration path. Arch, OpenCM, and PRCS2 could be in the running, and Arch has that multi-repository support going for it. But I'd say Subversion is the best thing going as of right now.
I have a listing of all known SCM software for Linux at http://linuxmafia.com/~rick/linux-info/scm.html [linuxmafia.com], in case it will help.
Rick Moen
rick@linuxmafia.com
Re:Subversion vs CVS (Score:5, Informative)
* Real copies and renames. The Subversion repository doesn't use
RCS files at all; instead, it implements a 'virtual' versioned
filesystem that tracks tree-structures over time (described
below). Files *and* directories are versioned. At last, there
are real client-side `mv' and `cp' commands that behave just as
you think.
* Atomic commits. A commit either goes into the repository
completely, or not all.
* Advanced network layer. The Subversion network server is Apache,
and client and server speak WebDAV(2) to one another. (See the
'design' section below.)
* Faster network access. A binary diffing algorithm is used to
store and transmit deltas in *both* directions, regardless of
whether a file is of text or binary type.
* Filesystem "properties". Each file or directory has an invisible
hashtable attached. You can invent and store any arbitrary
key/value pairs you wish: owner, perms, icons, app-creator,
mime-type, personal notes, etc. This is a general-purpose feature
for users. Properties are versioned, just like file contents.
And some properties are auto-detected, like the mime-type of a
file (no more remembering to use the '-kb' switch!)
* Extensible and hackable. Subversion has no historical baggage; it
was designed and then implemented as a collection of shared C
libraries with well-defined APIs. This makes Subversion extremely
maintainable and usable by other applications and languages.
* Easy migration. The Subversion command-line client is very
similar to CVS; the development model is the same, so CVS users
should have little trouble making the switch. Development of a
'cvs2svn' repository converter is in progress.
* It's Free. Subversion is released under a Apache/BSD-style
open-source license.
CVS operates on a per-file model (Score:2, Interesting)
This leads to the following problems:
Creating a branch or a tag visits (and writes on) every file in the source tree, so it takes a long time. For example, the gcc folks would like to create periodic snapshots of their source tree and publish the snapshots. One step in doing this is tagging all the files. Well, creating that tag writes information into every source file and takes HOURS.
Renaming a file is not supported. All the history information in CVS is associated with "foo.c". If you want to rename "foo.c" to "bar.c", you actually have to create bar.c and then delete foo.c. This loses all the history associated with the old foo.c.
Directories are even worse. There is no way to delete a directory in the CVS repository (that's what all the "prune on checkout" kludgery is for, to delete empty directories in the client work area that should not even exist in the first place).
When I edit source, I often edit more than one file. I might edit 10 files in 5 separate directories. CVS has no notion that my changes are one "unit of activity". The GNU project uses ChangeLog files, which manually tie the 10 changes together and actually work very well. But it would be even better if CVS knew that when I committed 10 files, it's all part of one changeset, not 10 separate changes. That makes it a lot easier to backport patches from development branches to stable branches, to figure out what some other guy did (hmmm he changed foo.h, I wonder what went along with that change?)
These are all well-known problems to people who use CVS a lot. Newer source control systems (bitkeeper, subverrion, arch) all have the idea of changesets in some form or other, and all have better ways of implementing whole-tree operatings like tagging and branching.
These are just the "data model" problems. The standard CVS server has other implementation problems -- that is, problems that could be fixed just by improving the server, without changing the millions of cvs clients in the world. One big problem is that CVS needs write access to the files, even for read-only operations such as anonymous checkout, and does excessive disk I/O, even for read-only operations. This is particularly annoying because CVS doesn't guarantee checkout consistency across a whole tree anyways, but only a single directory! This is no big deal in a departmental cluster but it becomes a serious issue for public open source servers that are trying to scale up to serve the whole world and do it with limited resources.
sounds cool (Score:4, Interesting)
I really hope that building ancillary tools like nice clients (wincvs) and useful add-ons (bonsai) is easy enough to do, because that's really where the critical mass is wrt widespread adoption.
Re:sounds cool (Score:2)
tortoise cvs [tortoisecvs.org] if you're ever in a win environment.
Re:sounds cool (Score:1)
I don't use wincvs too much, but it's really easy to train people on, and despite its quirks, it's is pretty nice.
Re:sounds cool (Score:4, Insightful)
Re:sounds cool (Score:4, Insightful)
I really hope that building ancillary tools like nice clients (wincvs) and useful add-ons (bonsai) is easy enough to do, because that's really where the critical mass is wrt widespread adoption.
Most of the subversion functionality is actually in a library, which makes it a lot easier and more robust to build gui clients and such for subversion. CVS, by comparison, is only accessed through the command-line client, so cvs gui clients have to execute the cvs binary and then parse the output, which as you certainly can imagine, is cumbersome.
Re:sounds cool (Score:2)
Anybody who doubts this should try reading the source code to cvs2cl [red-bean.com]. All it does is build a CHANGELOG file based on the developer comments at checkin, so it should be pretty straightforward, right?
Not nearly. I wanted to make some other CVS reports; when I looked at all the rigamarole that cvs2cl has to go through, I just gave up. With enough time my brain could have handled it, but my stomach never would have.
Atomic checkins are a must... (Score:5, Informative)
If something goes wrong during a CVS checkin, then all hell can break loose.
Re:Atomic checkins are a must... (Score:2)
Wait, I thought Perforce was heavily based on CVS? Was I wrong?
Re:Atomic checkins are a must... (Score:3, Informative)
Re:Atomic checkins are a must... (Score:1)
Re:Atomic checkins are a must... (Score:4, Interesting)
If there was a way in CVS to begin a transaction, then do multiple checkins, then commit/rollback that transaction atomically, that would be wonderful. It would be impossible for one person to check out someone else's partial checkin.
If Subversion is getting this feature, or even has this already, it will be one of the best "selling points" to replace CVS!
Re:Atomic checkins are a must... (Score:2)
Re:Atomic checkins are a must... (Score:3, Informative)
while perforce is not open source, they still grant a free license for 2 clients. this is enough for toying with my g4 and ibook. additionally, all the manuals [perforce.com] are online, and so are ports [perforce.com] for many different systems. there are plugins for many ides, and a web-gui based on html-forms. what i like the most is the relative ease of use of all parts involved.
until someone comes up with a stable and usable open-source tool, perforce might serve any home-user's needs.
Re:Atomic checkins are a must... (Score:2)
Re:Atomic checkins are a must... (Score:2)
The disk space argument is valid I suppose. But what would _really_ save disk space is a way to compress the source repository, either everything or just the older revisions. My $CVSROOT directory is huge and most of that is stuff I will probably never need to access.
Or if space is really tight, a way to selectively forget about older revisions. I have a bunch of very large text files under version control, in fact they are word lists for ispell(1) and similar programs. An operation like sorting the list into alphabetical order generates a huge diff, but the log message is entirely sufficient to describe the change. I'd like to cut out some of the version history so that only log messages are preserved for older versions - you wouldn't be able to check them out, but I wouldn't want to anyway. So far the only way I can see to do this is to hack the RCS files by hand.
Re:Atomic checkins are a must... (Score:2)
Please ignore.
--sex [tilegarden.com]
filesharing? (Score:1, Funny)
Off Topic?? (Score:2)
see the File sharing link directly from the freekin frontpage. This was meant for humor, but obviously the moderation has no sense of humor. Off topic was a bogus moderation though.
Subversion is far better than CVS (Score:5, Interesting)
For example, CVS stores its repository in a series of diffs in a directory structure, and the directory structure parallels the development tree. The difficulty is, directories in the cvs backend are therefore not versioned! Thus, moving files around, and re-working the tree, are not handled correctly in cvs. In subversion, the entire repository (dirs, files, and all) is stored as a single coherent revision; a subversion repository is an array of coherent tree/file groupings. As such, correct handling of directories occurs automatically. Also, atomic commits (something cvs lacks) are handled much more easily in this model.
Let me also say that the design of subversion is absolutely excellent. The design is properly decoupled and properly abstracted. Architecturally, it is greatly superior to cvs, and substantially superior to several commercial alternatives. I would imagine that the low-end source control products (PVCS, SourceSafe) will have significant difficulty staying alive once Subversion is widely deployed and tested.
Re:Subversion is far better than CVS (Score:2)
Re:Subversion is far better than CVS (Score:2)
To rename files in CVS, you remove the old file and add it as a new file. The semantics of this are well-defined, and you will get a consistent view of the tree no matter which version you check out. It's simplistic, but it works. The one thing that is a bit clunky is the fact that old, empty directories hang around, but that really isn't a big deal in practice.
Re:Subversion is far better than CVS (Score:2)
But this new file does not have the history of the old file, you can not check out last weeks version of it and it is not included in diffs of changes that spanned multiple files. Deleting and adding, though it may be well-defined, is also a really ugly and non-intuitive way of doing it.
CVS has had its time, there's no reason to defend it any longer. CVS is being maintained, but it is not really in development anymore. I'm also pretty sure that I read somewhere that a significant portion of the CVS developers are in fact working on Subversion these days.
Subversion will replace CVS, no question about it, it's only a matter of time.
Re:Subversion is far better than CVS (Score:3, Insightful)
It does if you add it (or automate adding it with a simple cvs-rename script). However, it's not clear that that matters much.
you can not check out last weeks version of it
Sure you can: if you ask for last weeks version of the software, it will contain the file under the old name. If you ask (somehow) for the individual file, CVS will tell you that it didn't exist at that time, which is correct and consistent. It would be inconsistent if I got a week old version of "newname.c" if "newname.c" didn't exist at that time. I do hope Subversion doesn't do that.
and it is not included in diffs of changes that spanned multiple files.
Huh? Of course, it's included. The diffs will contain a deletion for the old file and an addition for the new file. That is exactly what should happen. I don't think "diff" even supports any other way of renaming.
Deleting and adding, though it may be well-defined, is also a really ugly and non-intuitive way of doing it.
Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse.
Re:Subversion is far better than CVS (Score:2)
Doesn't matter much to whom? To you? Then fine, you can keep using CVS; we'll tell the SCCS Police to make an exception for you.
Or are you saying that cross-rename history tracking doesn't matter for all developer everywhere? In which case, I'd love to hear more about how you checked with them. I must have been out when you called.
CVS renaming trick breaks history (Score:3, Informative)
Case in point: Quite often, during code reviews or programming sessions, I come across bugs or bad programming methods that exemplify a certain fundamental lack of experience or understanding on part of the author. Using cvs annotate I can determine exactly who wrote the line(s) in question, discuss the problem with the culprit and, if I do my job right, hopefully ensure that the mistake is not repeated. Without the annotation feature, I would have to ask each team member whether they wrote the code in question. Too often it happens that they don't remember. We have had some major directory reorganization the last few months, and at one point all of our files lost their history simply because of a single directory renaming operation.
The remove/add renaming trick damages the projects' collective memory. You end up with bits of the past that are simply missing.
Re:Subversion is far better than CVS (Score:2, Informative)
Manually tinkering with the CVS metadata should never be necessary, especially for something so common as moving a file.
"Of course, it's included. The diffs will contain a deletion for the old file and an addition for the new file. That is exactly what should happen. I don't think "diff" even supports any other way of renaming."
That is exactly the problem: diff does not support any other way of renaming. In fact, diff does not support renaming at all; it supports only deletion and addition, which is not the same as renaming. With deletion and re-adding, the history of the new file does not indicate that it was moved from another location; it appears to have been spontaneously generated. You are still thinking in terms of diffs, and assuming that the limits of diffs are the limits of source code control. Diffs are the very architectural drawback of cvs; with subversion, you can get a history that indicates "this file was moved here, then there, then there, then this directory was created and that one deleted, etc." ALL of that is impossible with cvs, and all of it is quite common.
"Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse."
It would be difficult to be worse; cvs does not even handle renaming at present, but only deletion and subsequent addition, which is not the same. The authors of the original cvs are the ones writing subversion, because they realize cvs's serious limitations in this regard. CVS also has limitations in other regards, like lacking atomic commits. This would be possible to implement in cvs, using diffs, but it would be very hacky.
$Revision$ (Score:2, Interesting)
If there aren't any changes to the file in my new tagged & branched release, that $Revision$ variable will stay the same between releases. This is irrelvent for all my other files that aren't web-related, but the ones that are can remain cached in a user's browser as long as there haven't been changes to the file (this is especially helpful if I have large javascript library files that would otherwise slow down loadtimes a lot).
However, I don't see how I can do this using Subversion. It looks like the version for all project files is incremented everytime a single file checked-in.
Is there an alternative or better technique than what I'm doing by using Subversion? I like its advantages over CVS and would like to experiment with it more!
Re:$Revision$ (Score:4, Informative)
LastChangedDate
The last time this file changed. Can also be abbreviated as Date. The keyword substitution of $LastChangedDate$ will look something like $LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $.
LastChangedRevision
The last revision in which this file changed. Can be abbreviated as Rev. The keyword substitution of $LastChangedRevision will look something like $LastChangedRevision: 144 $.
Thanks! (Score:1)
Hmm...I better go read that manual. I thought I had gone over everything already. It was a while ago during the whole Linux kernel and Bitkeeper licensing "debate", but I probably skimmed it too fast as well.
Thanks.
Re:$Revision$ (Score:1)
Re:$Revision$ (Score:2, Informative)
Without going into all the details of how I currently do things, another user, xlv, has already pointed out to me, the LastChangedRevision is what I was looking for.
I'm actually reading the docs at http://svnbook.red-bean.com/book.html to increase my understanding of Subversion right now.
arch (Score:5, Informative)
Aegis is another one (Score:1, Informative)
Re:Aegis is another one (Score:2)
Re:Aegis is another one (Score:2)
I haven't actually used Aegis, but I assume that since the submitter also submits a test case, the submitter could "invent a test" as you put it that roughly corresponded to the way the new code is more "elegant."
I don't know if Aegis has this, but I'd like to see "benchmarks" in addition to "test cases." A test case basically either passes or fails, but a benchmark would return a score, so one could then submit a change that did not break anything but resulted in smaller line count, fewer branches, smaller object size, faster exeution, whatever without breaking other test cases or worsening other benchmarks. You'd probably also need to define a utility function that would combine benchmark scores to determine which combination was better, and I expect people would frequently submit changes or even branches to that utility function as their thinking evolved on how they'd like to optimize various trade-offs.
Re:Aegis is another one (Score:2)
Long story short, I believe that you've been misinformed. Feel free to correct as need.
Re:arch (Score:2, Interesting)
What's really new about arch is that it makes version control decentralized, rather than merely distributed, as CVS and Subversion do. In arch, any branch, any developer's private work area can be regarded as a repository of its own, with a global name space for developers, repositories, and branches, to manage this.
With CVS and Subversion, the repository is still a centralized entity. Compared to arch, these systems are still at a similar conceptual level, while arch adds something that is really new.
Re:arch (Score:2)
Sounds a bit like Bitkeeper [bitkeeper.com], the commercial, decentralized source code control system being used by Linus and a bunch of the Linux kernel hackers these days.
Okay, I will... (Score:2, Funny)
I am now Dimwit 22.16.
(Subversion - sub-version...get it? Ha ha? Ahhh...nobody has a sense of humor these days...)
Re:Okay, I will... (Score:1)
Re:Okay, I will... (Score:1)
only problem with subversion (Score:2, Insightful)
Re:only problem with subversion (Score:1)
Do your homework first. You don't need apache for local projects.
~velco
Re:only problem with subversion (Score:1, Insightful)
Re:only problem with subversion (Score:2)
Re:only problem with subversion (Score:2, Informative)
Re:only problem with subversion (Score:2)
some experiences (Score:5, Informative)
Since Subversion is now in Debian unstable, it's really easy to install. Compiling from source is a bit of a hassle due to all the dependencies, especially on the apache2 libs.
So far, I've not had a bad experience. No data loss or anything. And I'm very, very happy that I can finally get rid of pserver.
Subversion impressed our company developers by its speed (subjectively, considerably faster than CVS for comparable operations) and its user-friendlyness. It's the details, stuff like automatic detection of binary files, that makes life for the dev people easier.
For the admin, the fact that it runs via apache2 makes your life much easier, especially when it comes to firewalling and access control (user and passwords, etc.) - in a corporate network, you could easily plug it right unto your LDAP server for authentication, for example.
Two things are holding Subversion back right now, IMHO:
a) lack of a wincvs/tkcvs equivalent. Rapidsvn is making progress, but it's still very much alpha.
b) a couple things still missing, like understanding symlinks.
Re:some experiences (Score:1)
Re:some experiences (Score:2)
Oh yes, and the command syntax is suddenly sensible. For example, to check out subversion using subversion:
svn co http://svn.collab.net/repos/svn/trunk subversion
No CVSROOT, no -dgwana:gwana:gwana, no legacy silliness.
Migration? (Score:1)
Re:Migration? (Score:2)
[tigris.org]
http://subversion.tigris.org/project_faq.html#c
So far, its "only" a Python script. Very much in beta, the usual warnings apply, but they claim it's working ok.
As an example, the whole first
year of Subversion's own history was converted from CVS into a
3000+ revision svn repository. It took about 30 minutes.
[collab.net]
http://svn.collab.net/repos/svn/trunk/tools/cvs
Aegis aegis aegis aegis aegis! (Score:5, Informative)
Re:Aegis aegis aegis aegis aegis! (Score:3, Insightful)
Aegis (Score:2, Insightful)
Sounds good (Score:2)
I'll probably try it anyway, I'm just lazy.
Re:Sounds good (Score:3, Insightful)
I guess the moment one of the next generation version controls systems gets good IDE support will be the break-through for this IMHO needed technology improvement.
Bye egghat.
Al Viro's review of subversion (Score:3, Informative)
mistake I won't repeat any time soon. I've spent several months wading
through fairly disgusting code - block device drivers are not pretty,
ditto for devfs. I had more than once found myself grabbing Lovecraft
to read something that would be less nightmare-inducing. But _THAT_ takes
the fscking cake - I don't _care_ what Larry (or anybody else for that
matter) does to people who had excreted that code. No, wait - I _do_ care.
I want video of the... event.
I don't use BK, but you can be damn sure that I won't touch SVN. Ever.
Short and concise as ever.
http://marc.theaimsgroup.com/?l=linux-kernel&m=
Re:Al Viro's review of subversion (Score:2, Informative)
~velco
Damn... (Score:2)
How about this for a compelling reason; CVS's interface is HORRENDOUS!
Look, CVS has fantastic features, to be sure. But it has a horrible interface that's far more complex than it needs to be. I haven't even found a GUI front-end that can make it easy to use.
It's great to have powerful features, but not everyone needs all that power. 9 times out of 10, all I need is simple check-in and check-out with revision control. I don't need encryption. I don't need a million options for checking in and checking out.
I just find all this other stuff gets in the way. I'm a firm believe that if you want to use software at it's simplest levels, it should be simple to use. As you get to more advanced features, it's okay for it to get more difficult to use. But to make it difficult to do the most basic things just doesn't make sense.
I don't mean to slam CVS, but I'd just really like to see a simple to use alternative to it. Too many times I've gotten lost with CVS wondering exactly what the hell I had done.
Re:Damn... (Score:1)
For Windows there is an excellent GUI called TortoiseCVS [sourceforge.net]. It integrates with Explorer by overlaying icons on the files in the sandbox with own small icons indicating modified files, files with a conflict etc. You can perform all the important functions by simple context-menu commands on the directory, single- or multiple files.
This program is really the reason I started using CVS, it removed all the unnecessary cruft that is in WinCVS for example.
There is a move to make a TCVS like client for Subversion but I dont know at what stage it is at the moment
Re:Damn... (Score:1)
Re:Damn... (Score:3, Interesting)
That's what's ssh-agent is for, you upload your public key to the machine running CVS and the agent running on your machine authenticates you without a password.
cvs -d:pserver:anonymous@cvs.project.sourceforge.net:
Oh wow, yeah, now thats so obvious isn't it?
1. You can get rid of everything up to the "checkout" by putting it in your CVSROOT variable.
2. No subsequent updates/checkins ever need this information again as it's stored in the CVS data in the directory. So it's a one time deal.
Subversion replaces the cryptic CVSROOT with a "normal" url, so you'll be typing something like "svn co http://someserver/repository module".
Al Viro hates it ! (Score:2, Interesting)
Damn you. That thread got me to download subversion source and read it - mistake I won't repeat any time soon. I've spent several months wading through fairly disgusting code - block device drivers are not pretty, ditto for devfs. I had more than once found myself grabbing Lovecraft to read something that would be less nightmare-inducing. But _THAT_ takes the fscking cake - I don't _care_ what Larry (or anybody else for that matter) does to people who had excreted that code. No, wait - I _do_ care. I want video of the... event. I don't use BK, but you can be damn sure that I won't touch SVN. Ever.
found on The Linux Kernel Mailing-List [theaimsgroup.com]
Non-Apache 2 server? (Score:3, Interesting)
In comparison, CVS over ssh is secure and works pretty much everywhere. Many machines don't need to run a web server, let alone Apache 2, while ssh pretty much runs everywhere.
Re:Non-Apache 2 server? (Score:3, Informative)
A standalone subversion server is also in development, but I don't remember if it's scheduled for 1.0 or not. However, this is free software, if you feel like you need it, you can help developping it !
The point is, this is indeed a good remark, but not a showstopper. And the Apache2 svn server works just perfect for me !
Re:Non-Apache 2 server? (Score:3, Interesting)
As noted above, there is a standalone protocol in development. There's also a pipe module to exactly mimic cvs over ssh.
If you strip down apache's configuration enough, it doesn't eat too many resources, though (can't get exact numbers from here, sorry) and it pretty much runs everywhere itself.
Re:Non-Apache 2 server? (Score:2)
I'm doubtful (for now). (Score:4, Insightful)
Subversion does look somewhat better and cleaner than CVS. But there are lots of add-on tools for CVS that will need to get ported (GUIs, servers, web interfaces, IDE integration, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--CVS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.
It's been years since we have had any signficant problems with CVS; it seems to be just ticking along, doing its thing. So, I'm not convinced switching to subversion would be enough an advantage to outweigh the risks and retraining costs associated with it. I think it would take a number of large and very visible open source development projects switching to Subversion to give me enough confidence in it to try it.
Re:I'm doubtful (for now). (Score:5, Interesting)
Good point, but this is also a big concern of the Subversion folks. This is why subversion looks so much like CVS. The commands and aliases are almost all the same, and a great part of the comportment the users see also is.
The ViewCVS scripts has already been ported to SVN [collab.net], though it's not perfect yet, it does work. The GUI is pretty much in development indeed : RapidSVN [tigris.org] is a working one, yet not complete either. An Emacs mode, similar to the CVS mode, shouldn't bee too hard to code I suppose, this is just a matter of time, will, and knowledge of elisp
There was talkings about using SVN as a backend for a wiki too, this could be fun and really nice. A first draft had been coded by Greg Stein (if I'm not mistaken), but it was mostly test stuff.
Subversion still needs help and contributors. People keep whining about CVS not handling file renaming etc, and they also keep using complicated tricks to avoid those flaws. I know, I've done it too. The very same people look at subversion and say "mh, nice, but not mature yet, let's wait it grows up a little". I doubt it'll grow quickly on its own, it just needs some help from all these coders who *will* use it in a few months/years !
Believe me, once you've switched to svn, it just looks life is *so* easier. Try it, it won't bite, and you'll most likely love it !
Re:I'm doubtful (for now). (Score:3, Insightful)
Linux does look somewhat better and cleaner than DOS. But there are lots of add-on tools for DOS that will need to get ported (GUIs, servers, word processors, batch files, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--DOS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.
It's been years since we have had any signficant problems with DOS; it seems to be just ticking along, doing its thing. So, I'm not convinced switching to Linux would be enough an advantage to outweigh the risks and retraining costs associated with it. I think it would take a number of large and very visible open source development projects switching to Linux to give me enough confidence in it to try it.
PR for arch (Score:5, Interesting)
SVN is a huge and complex system that aims, for its 1.0 release, to be just a tiny bit more featureful than CVS. There's quite a large number of bugs. The complexity for repository administrators is pretty high. The developers are willfully postponing consideration of a lot of deep issues in revision control. If you follow the dev list closely
arch is a tiny, simple system that aims, for its 1.0 release, to be way more featureful than CVS. Although I don't think its ready for deployment in large-scale situations, early adopters tell me that they enjoy using it. arch, unlike svn, is very well positioned to compete (with just a bit more development) with BitKeeper, ClearCase, and others. arch can do a hell of a lot for the commercial free software world with just a bit of investment.
And, I don't know how you should interpret this, but svn has a handful of paid developers -- arch has none and, in fact, I'm literally days away from homelessness.
Go figure.
Re:PR for arch (Score:5, Interesting)
The reason why we chose Subversion over Arch, and probably a reason why Arch isn't getting as much attention as Subversion is, is because of Arch's dependancy on shell scripts. This removes any incentive for a heterogeneous software development shop to use it.
I can argue the merits of Subversion over Visual Source Safe to my clients, but Arch is a much harder sell.
Good luck on finding employment, by the way!
Re:PR for arch (Score:4, Insightful)
> it's largely written in sh]
Just as a small clarification on a technical issue:
1) In some sense, yes, that's an obstacle.
2) It is very portable among solid Posix and nearly-Posix systems. It's not terribly useful as it stands on cygwin because (I've been told) `fork/exec' is very slow on cygwin.
3) Most importantly, though, and a bit unlike SVN, arch is designed to be implemented more than once. It's tiny enough to rewrite (say, in Python or Perl) in just a few man-months. It's based in part on the idea of standardizing repository formats, exchange formats, and so forth. In other words, from the point of view of whether or not to support finishing arch, you have to regard it not just as a particular implementation, but as a collection of standards that are effective, simple, and cheap and easy to (re)implement in many different contexts. It's a bit like designing a cataloging system for libraries -- you think bigger than just one implementation.
(Regarding other comments in this "thread", about "get a job", or "you're just trying to steal funding from svn", etc. Well, those aren't bad advice/concerns/objections to discuss -- but I don't think the blog format really supports that kind of discussion -- so I'm going to let them go without direct reply.)
Re:PR for arch (Score:3, Insightful)
For instance, when I set up my project a few months ago, I did look at other code control systems, but CVS won because everybody had it practically installed by default, and it was good enough. Considering how many different commands there are to do very similar operations in arch, it'd be better for you to give it a proper intro methinks. The Linux Journal article just left me with questions.
Re:PR for arch (Score:2, Interesting)
There once was a company called Madge Networks (well, still is). In the early days, they made Token Ring cards that were clones of IBM cards. They didn't have the big name and reputation of IBM. They didn't have a significantly better product. So how did they compete? They were easier to deal with than IBM.
Are you as easy to deal with as the SVN team?
My impression is that you're trying to highjack funding from the SVN team by telling them that your product is better and collab.net should pay you instead. But collab.net want a CVS replacement for sourcecast and that's what they're paying for.
Re:PR for arch (Score:4, Interesting)
Are you ever going to make a Win32 version? How?
Re:PR for arch (Score:2)
There's no way somebody with your talent would not be snapped up, if you're known to be available. But I suppose you're not interested unless you can work on Arch fulltime?
I agree with the other respondent that the dependancy on shell scripts is a perceptual problem. Considered Python? Dependency on diff is not so great either. Actually, the binary diff used by Subversion and XDelta (the code came from XDelta I believe) is only a couple of hundred lines long, and very easy to use.
Re:PR for arch (Score:2)
In principle a version control system doesn't need to use diff at all. It could just store each revision of each file in full. That's probably what I would do if I implemented a VCS myself. Then if disk space gets tight, there can be a daemon which converts some of the complete copies into diffs against the latest version. But that doesn't need to happen on every checkin.
An interesting alternative to storing diffs, but still saving disk space, is to use compression such as bzip2 to squeeze redundancy between the different versions. If you concatenate all the different revisions in a single file and then compress it, you'll probably use just as little space as compressing an RCS file or other collection of diffs. But it might be too slow to do this in practice.
Re:PR for arch (Score:2)
If for the time beign you are not lucky, you should give up and go on, you surely are talented and able to find a job soon if you want to play by your bosses rules (that always works).
Whining you are broken will only get you "condolences" and things like that.
Re:Don't use IE dumbshits (Score:1)
Re:How does this compare to OpenCM (Score:2)
Personally, I would like a better comparison of these two.
Re: (Score:2)