Slashdot Mirror
Subversion 1.0 Released
Phil John writes "Subversion 1.0 has finally been released. The people who maintain CVS have given us a viable replacement for our de-facto (and aged) versioning system. If you're new to Subversion its feature list looks like fixes for everything that is wrong in CVS, renaming, directory structure and metadata version tracking, file deletion, proper management of binary files and it's pretty portable to boot." According to the download page, binaries may take a few days to appear.
According to the download page, binaries may take a few days to appear.
What's so good about a version control system that takes days for binaries to appear? That's a pretty big bug to work out. (fp)
This story seems to have jumped the gun a few hours; the 1.0 tarballs don't seem to be available yet.
However, you can download the latest Subversion sources from its Bitkeeper repository... no, wait...
Why? It's not like it's licensed under the new Apache/BSD license, is it?
Does someone have a mirror? This story is 5 minutes new, and the site it slowing down (aka took-me-5-minutes-to-load).
Cheers,
RoadkillBunny
Does anyone have a good website to compare subversion, cvs, perforce, clearcase and other software of this type?
It's not released under the Apache/BSD License . . .
It's released under an Apache Style license.
Google Cache since the site seems to be dying as we speak.
Your hair look like poop, Bob! - Wanker.
I think this can be used with WebDAV to provide the missing versioning functionality as well.
Consensus is good, but informed dictatorship is better
What is the matter with an Apache/BSD license? Why must it be GPL?
that was on their website six months ago?
(It's Slashdotted at the moment or I would check for myself)
There is always GNU arch. It's got some nice features that subversion does not have to boot! Such as distributed repositories, advanced merging, and GPG signed patches.
Is sourceforge gonna offer this service in their project hosting instead of CVS now? Or will they allow both?
Cheers,
RoadkillBunny
I've been using Subversion successfully for about a month (http://svn.pdtp.org). Unlike CVS, Subversion is actually sane. You can *gasp* delete directories from the repository! You can rename/move files within the repository without losing versioning (possible but highly cumbersome in CVS). Branching makes sense. It still lacks some of the features of Perforce/BitKeeper but overall quite nice.
So when does it replace Bitkeeper for the kernel?
I've been using earlier builds for my own codebase stuff, and while there are a few new concepts to get your head around, overall the system works very well. I haven't had any problems with corruption or loss, and everything I've needed to do has worked perfectly.
My congrats to the dev team for a good solid product.
For those looking to use it, befor eyou do, work out your versioned directory structure, it *is* kinda important (although not critical, you can move things around afterwards). For example, I have:
trunk/(project name)
tag/(project name)/(tag)
branch/(project name)/(branch name)
as my general layout. Other people may have other recommendations, but tags and branches etc are no longer this explicit thing, its just about where you put them in the "filesystem".
I don't think I'm going to try this version. I think I'll wait until they get to Superversion 1.0. Or maybe Superversion Platinum/Pro++ 1.0.
Find free books.
What a strange statement. Do you use XFree86? OpenSSH? There's any amount of such software out there under similar licences, and if the original BSD TCP/IP stack hadn't been under such a licence, it's doubtful the internet would be as interoperable as it is today, and if X hadn't been under the MIT licence, we'd be stuck with a bunch of incompatible proprietary windowing systems.
If I get this straight, Subversion runs on top of Apache. Isn't that a bit heavyweight for their purposes? It seems a bit odd to run a VCS on top of a webserver.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 Whoops, silly middle mouse button...
Is there a filesystem that uses subversion as it's underlying "device"? For linux?
Some time ago I worked with Rational ClearCase and the filesystem integration was really nice.
I've always hated that about CVS and Arch.
A revision control system should simply work in one UNIX account across all users - it's easier to administer and is much more secure.
Here's a comparison with 10 popular replacements
n .html
http://better-scm.berlios.de/comparison/compariso
Some time ago Doug Rabson posted a wishlist of features that would be needed to move FreeBSD to subversion (from CVS). Any idea on progress on these features? The site seems to be slashdotted.
i assume the client libraries are apache/bsd licensed. if they were GPL, then SunOne/Forte, Visual Studio, C++ Builder, and other systems could not include plugins for Subversion. So, we'd be stuck with either propritary solutions like source safe and clear case, or stuck with CVS access via fork() as many applications do now.
If you're really annoyed, write tirgis and tell them GPL with LGPL client.
This news post really does nothing to explain why Subversion is so much better than CVS.
Subversion is, in essence, a reimplementation of CVS without the limitations of CVS.
It has basically the same functionality as CVS, but is based on a BerkeleyDB backend instead of a simple filesystem approach like CVS. This means, among many other things, that you can move files from directory to directory and rename them without orphaning them.
This is, IMHO, reason enough to switch. (And was reason enough to switch for me a while ago.)
SVN can do binary-file diffs, tracks submissions of multiple files as part of the same revision, and if memory serves me correctly, does O(1) branching and tagging.
For those of you who, like me, use TortoiseCVS to do version control in windows, there is TortoiseSVN which works like a charm and provides all the functionality you're using in TortoiseCVS with some nice extras.
I could go on at great length, but the Subversion team can probably do a much better job explaining this than I can, so go to their web site instead.
Quite honestly, I think that Subversion is so much superior to CVS that it will completely replace it, and I haven't got anything to do with the project. Once I switched over, I never looked back.
1.0 release means that SVN now supports everything that CVS does, with a few extras. From here, they are planning to work on new features.
I've heard some bellyaching over the license already (boo hoo). BSD code is Gratis and Libre, and if the Subversion team isn't losing sleep over MicroSomeone ha>oring their project into one of their own, I won't either.
Please don't turn this discussion into another license vs. license argument, and have a look at the project for its real merit.
"The wise man proportions his belief to the evidence." -- David Hume
The main site seems to be slashdotted. There appears to be an online book on the subject here
Version Control with Subversion
Draft Revision 8770
Ben Collins-Sussman
Brian W. Fitzpatrick
C. Michael Pilato
-jim
My project team has been using subversion for over a year and has nothing but good to say about it. I am really surprised so few people have heard of the project.
More secure to have a patchwork of internal user tracking built into the app instead of using the OS's user tracking?!?!? I don't think so, especially since you can use advanced permissions like ACL's to block access to subtrees despite what the version tracking system might think.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
And CVS uses RCS as a back-end. So... what's the big deal with binary files?
My group uses CVS every day. It does a great job for us.
However, some other groups in my organization like alternatives like PVCS. Now I have little against PVCS (price tag being one thing, and some crappy network functionality that likely has been resolved by now).
These people mostly like PVCS because it can do stuff like renames.
And I like renames too. And therefore, Subversion is pretty compelling. Yay! Congrats to the team, this is pretty exciting, I've been watching subversion for a couple years now. Yay!
Can someone give me a quick overhaul of what CVS acutally is and does? I am just starting to move from Proprietary to Open Source for my developments, and wonder what exactly CVS is, in the Proprietary world, most people just use a WinServer/SMB to share code, how different is CVS? I know it is pretty hard, but I want to know the exact concept of it and how exactly it will help improve efficiency/etc. Once I am done migrating from prop/opensource, i will probably write a paper or article on it, it is a rough journey but once you are halfway there, you fell like you just took on the world and won.
Sig: I stole this sig.
what do you call it when even the google cache is slashdotted ?
Do not mod up people who point out cut-and-paste trolls logged in.
Many of these are folks who post plagarized articles and then point it out with another account to gain karma.
The problem I have with these systems is, that as far I know, you have to check out files, work on them and commit them back to the revision system.
This is fine for most types of code, but for web development you really do not want to maintain a different local webserver for each developer, so my question is this:
Is it possible to work several people on the same files and still have version control?
http://www.red-bean.com/sussman/svn-anti-fud.html
Also, #svn channel on freenode irc is helpful.
SourceForge said in a FAQ (IIRC of course) that they are waiting until a production version of SVN comes out. Now, when will they implement it? I'm waiting pretty anxiously.
Does it check for SCO IP on each commit?
No article should remain without a [bad] SCO joke.
How are multiple repositories (even in CVS for that matter) handled? Anyone have any experience with either Subversion or CVS?
envfs is a good place to start.
Your assertions are totally unawarranted. Ifs are meaningless in History, except as a fun exercise.
One could say that to the contrary a copylefted X Window System would have had less forking (widgets, servers, extensions, drivers) and thus the main RI would have been richer, more useful.
And we would be totally unable to prove it either way.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
... try having a sysadmin that prefers debian and see how long you have to wait. Sigh. I do like subversion lots though! :)
http://www.red-bean.com/sussman/svn-anti-fud.html
Arch doesn't require any accounts for read-only access. Write access requires 1 account at minimum. If you want to have multiple people use the same account, that will work fine. (I'd recommend using ssh public-key authentication, though, since shared passwords are always bad policy)
Supported write protocols include webdav, sftp (the one that's part of ssh) and ftp. Shell access is never required.
is anyone using this in a large professional setting? I've been tasked with rebuilding the CVS server at my gig, and I'm almost done, but how hard would it be to convert and existing CVS repository over? I will be testing the setup for a few weeks after install, so this may be a good time to try out Subversion. anyone with exp please share your thoughts. tia
CB
free ipod and free gmail!
Subversion (well mod_dav_svn) is built on a filesystem-over-http protocol, of course you can use it like a filesystem, on just about every platform, or from many applications, or through your web browser (to read it, anyway).
Are you saying GPL projects don't fork? For an early counterexample, see emacs/xemacs. Even with the linux kernel, every distribution now maintains its own version, and it's rather hard to drop a vanilla Linus kernel into Red Hat or SuSE or Mandrake and expect it to run the same. But forking wasn't the point. The point with the GPL is that commercial vendors would not have picked a windowing system based on it, because shipping it as part of their system would have meant GPL'ing every graphical program they wrote, thanks to the virality clause. Name a single counterexample of a GPL'd library shipped as part of a commercial OS.
More secure to have a patchwork of internal user tracking built into the app instead of using the OS's user tracking?!?!?
Yes it is. It's also easier to set up and administer. Why the heck is needing root access to add users a requirement of a revision control system? It's nuts.
Stop thinking like a UNIX programmer and start thinking like a non-technical person.
...you could do a lot worse than TortoiseSVN (also on tigris.org). It's an explorer shell plugin with icon overlays. Open up windows explorer, right click files to comit and whoosh...it's done.
Also has a visual diff and all sorts of other goodies in it too. There's also a (somewhat unrelated) project of the same ilk for CVS called, unsurprisingly, TortoiseCVS (different developers IIRC, same idea though, hence the similar name).
I've been using Subversion for the last 6 months and TortoiseSVN for the last 5, never had any data corruption or borked repositories, it Just Works(tm).
What I like is that the developers started eating their own dogfood fairly early on and have been self hosting for a fair while now, so that shows you how much faith they have in the system.
I am NaN
I think slashdot may have jumped the gun here, and I hope that the slashdotting of their web server is not going to cause them problems with actually getting 1.0 out the door, which is supposed to happen sometime Monday (timezone unknown).
see shy jo
Name a single counterexample of a GPL'd library shipped as part of a commercial OS.
Let's take two examples here: first, zlib. It was released under the BSD licence, not GPL, because it was important to wean people off the LZW-patent-encumbred compress. And it made it to commercial systems. But take, on the other hand, the readline library. This could have been immensely useful to a lot of commercial vendors, and Stallman knew it, so he used the GPL (not even LGPL) to try and "force" third party code to be GPL'd. As a result, nobody outside the free software world uses it.
Apparently Subversion 1.0 doesn't support "sharing", where the same file appears in more than one place in the source tree. That's a lack. Microsoft SourceSafe does that, and it helps avoid those annoying situations that result in long include paths.
there's already an eclipse plugin available.
I am NaN
It's a versioning and indexing program right (keeping track of file changes and so forth) so is it used on itself? Kind like compiling a compiler in another?
I can't really check since the article's slashdoted.
Trolls dont like to be Flamebait, because they burn so well. Protect our Troll heritage!
1. Subversion does NOT require Apache. It can use either Apache OR svnserve as its network server.
d .html
2. Want decentralized subversion? Check out the svk project at http://svk.elixus.org/
3. Best benefits over CVS? Well, its basically a 4-year redesign/rewrite/replacement of cvs by people very familiar with cvs (ie wrote the book on cvs and runs a company specializing in cvs services).
a. Cheap copies (constant time, store diffs only so branch often if you want even on very large projects).
b. Directories and metadata are versioned too.
c. You can move files and directories without losing history.
d. Atomic commits! Issue a bunch of "add" commands, then a "commit". The whole thing rolls back if any of it fails and the revision is per commit (not file).
e. Other benefits may be more important to you than these (but these were enough for me to switch from cvs to svn).
4. Is svn 1.0 ready for prime-time? Subversion project has been hosting itself for almost 2 years now and they never lost any code. For the ultra-paranoid, you can configure it to keep all bsdb logs so you can roll back every transaction since the beginning of your repository creation (but that would be silly).
Don't forget to see:
http://www.red-bean.com/sussman/svn-anti-fu
And irc: #svn on freenode
I agree with you, but I think that some people can get angry when code under the bsd licence is used in a closed source project (case in point: OpenBSD in Windows Server 2003). If you are interested in the multitude of "officially" open-source licences, look at opensource.org/licences
MOUNT TAPE U1439 ON B3, NO RING
How about a web interface to sudo for adding user accounts? How about a web interface to LDAP with inherited permissions for accounts created under a non-root level account, heck how about any of the dozens of ways a sysadmin adds accounts on a daily basis. Basically reinventing the wheel might be a smidge easier for the non-technical person but it CERTAINLY is not more secure then the tried and tested systems that already exist.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Am I? That was not the point, but that copyleft (in general) help prevent proprietary forking that has all but killed BSD, and therefore almost all Unix and X by extension.
For libraries, if you like, there's always LGPL.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Problem here is that many open source projects for Microsoft Windows will compile only on Microsoft Visual Studio, which costs over 1,000 USD for one seat. Will the Windows version of Subversion compile cleanly on MinGW+MSYS? Or will I have to try to compile the UNIX version on Cygwin? I'd go look myself, but the site seems to be slashdotted, and even the Google Cache runs extremely slowly because Mozilla won't render anything until it has failed to fetch the CSS from the slashdotted site.
it always worries my when open source software relies on closed-sources or standards.
Very little demand seems to exist for completely open-source PCs. I haven't seen many computer manufacturers ship their machines with LinuxBIOS or any other Free firmware. Therefore, on most computers, LILO and GRUB (the most common Linux bootloaders) rely on a proprietary BIOS. Even if you exclude BIOS from consideration, most Free programs running on a proprietary operating system rely on the proprietary system's runtime library (e.g. msvcrt.dll, Sun libc, etc).
How about a web interface to sudo for adding user accounts?
/dev/null, whatever. But still, my paranoia's inflamed. By giving them a user my system's at least recognizing their existence, and that makes me uncomfortable because I am uncertain my knowledge of UNIX is complete enough I've locked off all the possible manners in which they could take advantage of that.
You're suggesting I put up a web accessible chmod root script just so someone can run a version control system?
I can see that for some people's situations, using the unix account system would be very attractive. However, not everyones'. I, specifically, have been needing to set up a version control server of some sort. I will probably wind up doing so on a personal machine. It is concievable at some point I could give other persons access to this server. If so, I do not want anyone who has access to this CVS server to have any sort of other abilities on my system. Yes, yes, disable FTP, set shell to
From a security perspective, every moving part you add to a system is a chance for something to go wrong. A versioning system implementing its own internal security system adds a hell of a lot of moving parts, but they're all well contained off in userland, there's some vague notion of a sandbox there. A versioning system using the OS user system is adding a very small number of moving parts but those moving parts are in a much more dangerous area...
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Ever heard of the LGPL?
Use Arch with a WebDAV backend, then all you need is a WebDAV account, not a UNIX account. Problem solved. (I've also seen tools for setting up sftp-only accounts and the like).
Then why, when I create a shortcut in Explorer.exe of Windows 2000 or Windows XP, do I get an ordinary file whose name ends in .lnk rather than a junction? And can the junction utility link to a file rather than to a folder?
Looks neat. Just checking:
Has anyone used this on Mac OS X / with xcode? I'm interested in doing so; if I want to, do I just sit down and follow the instructions or are there any gotchas or OS X-specific quirks I may run into that I might need to be aware of?
Thanks.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
And yes, I know that some of you think this is a terrible, horrible idea and that my keyboard should be confiscated for even suggesting it. But this ability is on my "holy grail" list for version control systems, and I won't rest till I find it!
If you are really worried about it then use a 'jail' or 'chroot' setup.
[Set Cain on fire and steal his lute.]
I have to look through it, but based on the way it works, it probably has two more benefits:
* Easier to set up and maintain user accounts (CVS requires setting up shell accounts)
* More secure. One can spoof history with CVS, corrupt the thing, or whatnot.
I'd like to see Sourceforge move to SVN, and see what happens...
May we never see th
Linus wants a distributed system, which Bitkeeper is.
Did Linus evaluate GNU Arch? If so, what did he find wrong with it? One of the goals of Arch is to replace Bitkeeper. Yes, there exists one known feature that Arch lacks compared to BK, namely copying files within a repository while forking its change history, but why did Linus find this a showstopper? Or has Arch progressed rapidly since the BK decision?
This is the first stable release of one of the most influential open source tools. It marks the beginning of the global transition from CVS to SVN. Aside from CVS, I think that only gcc (good, free compiler available for many platforms) and perhaps a few parts of the GNU toolchain could be considered as influential. I would say that this is of exceptional importance to anyone using or working with open source or developing software.
May we never see th
I'd say that this is more of a flaw in the UNIX permissions scheme, that normal UNIX boxes don't support ACLs (or let non-root accounts create limited user accounts, which would provide some similar functionality).
May we never see th
...it's meant as a general file versioning system. However, there are indeed various hooks so in theory you could set something like this up. Have a look at the subversion book (linked elsewhere in the comments).
I am NaN
Dang... got my nice, bound copy of the book too soon... they've gone through almost 200 revisions since I printed it:(
I haven't used this but using this to loop back as a local filesystem, you should be able to access the latest snapshot transparently. Saves time on checkouts ^.^
VIVA1023.com | Political Fashion.
Yeah, you're right (not the original ac here, just someone who agrees with you)
Is this likely to get Linus to switch from Bitkeeper? If not, what needs to be done to make it a suitable replacement?
Or am I wrong? Yes, I know VS is an unholy horror, but some of us are stuck with it for work. I use Jalindi igloo to interface with CVS, and would likely use subversion (heard nothing but good things about it) if I had 2 things:
1) the VS.NET source control plugin
2) a good way to "upgrade" an old CVS repository
I'm guessing #2 is supported, but #1?
where can I get the 1.0 src package
the master site only have the beta package,
and I have got the definative guide, and hope to use it as my scm tool.
As much as I'd love to see a Subversion filesystem driver in Linux, I am not sure if that would be possible. Would such a thing be legal under BitKeeper NDA to implement by Linux kernel developers?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
I've been following subversion for 2 years and waiting for it to be ready.
Last build we tried was a couple of months ago.
Try compiling it on different architectures (ours are i686-linux and hppa2.0-hpux11.00), mixing slight version differences, mixing which server you use (svn, http).
Then say hello to _constant_ intervention by someone who has admin privileges to recover your hosed repository.
I hate to say it, but now of course with 1.0 we'll try again. But I wouldn've thought they were a long way off based on our problems.
And this is with just 3 people using it on a test project? CVS has bugged me for years, but it can handle the basics without error.
I'm willing to admit that something we did could've caused all our problems (funny compiler flag or version, wrong switch enabled), but I can't afford the time spent trying to get a superior, but buggy, tool to just do the basics, even if the root cause is in some arcane step in the build process (which is truly hideous).
I wish them luck, but honestly I've never been able to figure out how all these happy subversion users ever got it to work.
There's still time though to pull the plug on our imminent order of Bitkeeper if by some miracle things have improved a lot very quickly.
Has anyone told Kommandante Ashcroft?
I knew these open source Communo-Marxian hippies couldn't be trusted...unlike the Real American Men who make up successful, for profit corporations like SCO
We haven't announced 1.0 just yet; we're going to do it sometime on Monday the 23rd. The Subversion team prepped the website and rolled a 'beta' 1.0 tarball over the weekend in preparation for Monday. We wanted to make sure there were no embarrassing bugs in the tarball itself (i.e. no "brown bag" releases due to a bad libtool or something!)
Thanks for all the nice comments. Stay tuned for the official announcement.
Arch has some very nice features, probably too many. It's so powerful that it scares people off.
Octopy looks like a promising qt gui frontend for arch to solve that problem.
"But you have recruiting ads on TV. Why do you need subliminal messages?"
. ht ml
"It's a three-pronged attack. Subliminal, liminal, and superliminal."
"Superliminal?"
"I'll show you. Hey you! Join the navy!"
"Uh, yeah, alright."
"I'm in."
http://www.macalester.edu/~coien/Simpsons/s12/4
Granted, it would be great to finally see Subversion nicely integrated with SourceForge, but CVS (the current concurrent versioning system used by SourceForge) while lacking lots of essential (at least for experienced developers) functionality, is free software nonetheless. What I am most concerned about is whether this new version of Subversion is already good enough to use with Linux, so one could contribute without the need to choose between restrictive EULA and being a second class citizen. Does anyone know what features exactly does it still lack, if any, for Linus to accept? I hope it would be legally possible to accept now, but I might be wrong.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
I can't be the only one that is unimpressed by Subversion.. and a little disappointed that this is the best the open source community can come up with.
When I first started reading about Subversion (a few YEARS ago), I was ready to be blown away. I thought it would be fast and powerful, yet light and minimal like CVS. And I expected features like distributed repositories and changeset management built in from the start.
But after using it for a while (and I have been using it for a couple major projects) and studying the design, I don't like it much.
One thing that's great: they stripped down the CVS interface, and removed all the confusing and conflicting commands and flags. svn now has a nice orthogonal command set, but still easy to use for a CVS old-timer.
But under the surface.. WOW a berkeley DB? Implementing a *versioned filesystem*? Talk about over-engineering!!
First of all, a versioned filesystem is not the right solution for version control. Version control is about *changesets*, not file snapshots. Subversion is concentrating on the nodes of the change graph, not the edges. Their solution is extremely "heavy". Changesets cannot be added to this model. It's possible to *generate* changesets from various snapshots of the tree (i.e., which sets of revision deltas make up a particular changeset), but that's also possible with CVS and a horrible hack.
A better solution would be designed around changeset management from step 1. And it wouldn't take X years to finish.
Second, the Berkeley DB is a key/value database. What the heck does that have to do with versioned trees?
Berkelely DB installations are difficult to back up, they can't be placed on network drives, they have locking issues, they create journals and logfiles and all kinds of junk. To back up our svn repositories, I'm just dumping the whole damn thing every night into a massive text file. Yeesh. (Actually it's not a text file, the binary files are dumped right along with the text, so it's actually a binary format).
Want another example of using berk DB where it shouldn't be used? The RPM package manager. A huge pain in the ass, but that's a rant for another day.
And yeah the WebDAV thing (which was installed by default when I installed svn from FreeBSD ports) sucks too. Maybe when I have some time I'll figure out the non-Apache dedicated server. But the WebDAV server should just be dropped completely, imo, it seems to just piss people off.
The Subversion folks should've been much more minimalist in their design. They should've aimed for the *simplest* design that could meet the requirements.
I've taken a look at Arch, and it has the opposite problem of subversion: damn nice internal design, but crappy interface (I recall the help text that listed commands was almost 200 lines long)!
Internally arch is great. It doesn't need any fancy database, all you need is a filesystem with atomic renames and other Unix-y features. It handles changesets, it handles distributed repositories, it handles "checkpointing" complete copies of the source code (so you don't have to spend a lot of time applying deltas to get to a specific revision)... it does it all once you figure it out.
The subversion folks should've taken Arch, cleaned up the interface, come up with some compatibility code for non-Unix platforms, and called it a day.
Ahh, but that would've been too easy.
Unfortunately, I don't think I have the money to go back for my master's or even just to go take some more courses at a local community college just to qualify for a cheap copy of Visual Studio. I already have upwards of $20,000 of student loans to pay back and little hope of finding a programming job anywhere in northeast Indiana, now that I'm competing with both laid-off 10-year-experienced programmers and Indian consulting firms.
Don't get me wrong, Arch is a very nice concept and it has some merits, but don't pretend there aren't advantages to Subversion's architecture. And the Subversion way of doing things is much more natural for a lot of existing professional software development teams. Arch is great for more distributed projects, but it's a bit less intuitive with respect to usage in a more traditional software development environment, and outright useless for cross-platform or non-Unix projects.
The BitKeeper model is so breath-takingly elegant. I used Sun's TeamWare (BitKeeper's predecessor) with great success, and am sorry to have to use Perforce in my current job.
The idea is that there are no branches. There are only repositories (each developer has one or more) and files. Each repository has full information of the version history, and there's no version control server.
Benefits of the BitKeeper model:
- Exchanging changes between developers without contaminating the common parent repository is safe and trivially easy.
- You check files in locally in your repository. So they don't even have to compile. It's often a good idea to check in files several times a day. Committing the changes to the parent repository is a separate operation.
- The repository is little more than a directory tree containing SCCS files. Should you want to liberate yourself from BitKeeper and go with a free competitor, chances are your SCCS tree can be accepted as-is by the new version control system.
- Since releases are managed as repositories (instead of branches), bug fixes can be propagated between releases as simply as within releases if there are no conflicts.
- Since there is no central server, transporting repositories, say, from hard disk to hard disk is as simple as copying the trees recursively.
$1000 for one seat? What version are you getting and where are you buying it?
Microsoft Visual C++ Professional Edition, which seems to be the cheapest version with an optimizer in the Microsoft price list.
You can get Visual C++, which is all you need to compile most open source stuff, for $100 so
The version of MSVC available to the general public "for $100 or so" is Microsoft Visual C++ Standard Edition, which contains no optimizer. I've read that the performance of its generated code is so poor that one might as well use an interpreted language instead of MSVC Standard for new apps or run the UNIX version of an existing app in the Cygwin API translation layer rather than try to compile the Windows version in MSVC Standard.
Any Apache authentication module will do... Also, because it isn't filesystem-backed, there is no need to have one system account per SVN account.
A nice *nix server running an Svn or CVS server can support a medium sized team of developers just fine. How the heck are you supposed to do this using Arch?
I'm really not sure what you're asking. Arch doesn't really need much in the way of hosting, so you could easily have your CVS serving machine host Arch archives as well.
Oh, you mean it really is designed to work primarily, if not only, with Unix-like operating systems?
One of Arch's assumptions is, indeed, a POSIX filesystem; basically every operating supports this, though. Unix-based systems natively, and Windows using Cygwin libraries or compiling with mingw. Actually, Arch users have encouraged the Cygwin team to shake out some bugs in Cygwin's long file handling support, so first-class Win32/Cygwin Arch really isn't that far off. Some of Arch's features (like revision libraries) take advantage of hard links if they're there, so some things may end up taking more disk space on Windows than Unix, but everything works fine.
Arch is great for more distributed projects, but it's a bit less intuitive with respect to usage in a more traditional software development environment, and outright useless for cross-platform or non-Unix projects.
Yep! Arch's design is primarily as a distributed SCM; there's nothing keeping you from only using the one centralized archive in a centralized development model, though; you just have everyone use one branch. It really can be used just like CVS in that respect if you want to, just the command syntax is slightly different. Hell, I'm developing software in a centralized archive using Arch right now, though I'm the only developer contributing code.
Why do you say Arch is "outright useless for cross-platform" projects? I'm curious to hear what you have to say.
Anyway, barely compiling for the last three weeks isn't exactly stable Windows support that I would feel comfortable rolling out into a corporate environment for professional software development work. Like I said before, Arch is a great concept, and I'd love to see more done with it, especially in terms of getting it to work out-of-the-box with Windows (i.e. I can roll it out to a development team with a single installer) so it was useful for cross-platform and Windows development. Until then, it's great for Open Source projects that themselves have a more distributed model of development which is nicely matched by Arch's capabilities.
and since the site is down, I can't check to see if they answer it, but why didn't they just add the features to CVS?
If anybody's wondering about how long it takes to switch from CVS: it's about half an hour before you see it start to pay off.
And if you're used to using CVS through ssh, it's even easier with SVN: svn co svn+ssh:///host/path/to/repos/trunk repos
All that's left to do is get used to the different keys. Oh, and instead of doing a 'svn up' before committing, use 'svn status' -- it actually does something useful.
I don't see a compelling reason not to switch.
Which is easier, adding a thin compatability layer between the host filesystem and an Arch-like implementation, or creating an entire opaque versioned filesystem from scratch, which completely ignores any existing features of the filesystem, indeed, any existing research in source code management?
The Subversion team, unfortunately, did the latter. They could've done the former in less than a year (step 1: come up with a good CVS-like interface, step 2: implement an Arch-like architecture that uses the filesystem, step 3: implement the missing parts on Windows.. the trickiest is the way POSIX files work, but others have done it already).
The only advantage to Subversion's "architecture" is the hype.
This is why I always metamoderate negative mods as unfair.
Stallman himself knows better. I noted zlib in another post; more recently, he supported the licence switch of the Ogg Vorbis libraries to the BSD licence. Even now, it's hard enough to push vorbis to commercial companies; LGPL wouldn't have had a prayer.
Yeah, definately OT, but just to let you know -after-, that is a great sig link. Thanks!
I think that some people can get angry when code under the bsd licence is used in a closed source project
Such people need to stop worrying about how other people's work is used, especially when they specifically permit that use.
I thought I saw a native build of arch for windows systems, or am I missing something?
There is: AnkhSVN.
VS.NET plugin. (project page, with downloads, normally here but currently blown away by the load. Maybe grab it from the Google cache of the page but that too seems to be overloaded. Oh well. You could always use TortoiseSVN instead.)
There was an old VC++ plugin "Subway" but it sucks.
Remember that what's inside of you doesn't matter because nobody can see it.
In CVS you could set the ownership of each project to a particular group to control commit access. Can you do something similar in SVN?
The best way to support the US war effort is to continue buying American products.
Not sure why the original poster said Subversion came from "the people who maintain CVS". They are two separate developer groups -- as far as I know there is no overlap between the currently active developers of CVS and Subversion.
:-). Subversion 1.0 wasn't actually out yet when he posted. We had released a beta prerelease, and were careful to say that 1.0 itself wouldn't be out till Monday. Oh well, win some, lose some.
Also, he was early
Anyway, it's almost Monday now, so check back soon at http://subversion.tigris.org/.
http://www.red-bean.com/kfogel
1) fine grained ACLs. The ability to control who commits and who does not.
2) Support for code reviews. In other words conditional commits or a commit que where code sits waiting to be reviewed. There should be ACLs regarding who can review too.
3) Support for builds and tests. The commit should not occur until the code builds and tests OK.
The best way to support the US war effort is to continue buying American products.
I had such a fun time the other day installing BerkeleyDB 4.2, Apache 2.0.48, and Subversion 0.37 from source. It just took me way too long to figure out the right configuration options to get the Subversion server installed correctly, so here are my notes. They're mostly stolen from somewhere on the Web (don't remember where), modified a bit with things I learned along the way. If this is useful to you, great.
../dist/configure
/usr/local/BerkeleyDB.4.2
./configure --enable-dav=static --enable-so=static --with-dbm=db4 --with-berkeley-db=/usr/local/BerkeleyDB.4.2
./configure --with-berkeley-db=/usr/local/BerkeleyDB.4.2
/repos> /absolute/path/to/repository
1) Download, build, and install Berkeley 4.2.52 with the default location; this is as simple as:
$ cd db-4.2.52/build_unix
$
$ make
$ su
# make install
make sure LD_LIBRARY_PATH includes
2) Download Apache 2.0.48 tarball and build it with the defaults:
$ cd httpd-2.0.48
$
$ make
$ su
# make install
3) Download a Subversion tarball (e.g. subversion-0.37.0.tar.gz) since that comes fully formed:
$ cd subversion-0.37.0
$
$ make
$ su
# make install
And then follow the directions for configuring Apache, which could be as simple as adding the following:
<Location
DAV svn
SVNPath
</Location>
Use Ctrl-C instead of ESC in Vim!
We replaced 2 huge SourceSafe and 8-10 enourmous CVS repositories with Subversion.
We kept dual copies for about two weeks before feeling concident (only two projects was actully active, but with > 140 developers).
This was in the 0.27 version and haven't had a single glitch!!! And 1.0 is even better, of course.
My only complaint is not supporting locking, but this is obvisouly on the way. Nice for stuff like Word documents and UML files.
GO SUBVERSION!!! Also try TortoiseSVN... it's the best client and integerates nicely with the explorer. If you use Linux, there are lots of options too.
I'm glad to know an informed statement like "Arch is crap" and limiting its user base to "3 brain dead people" can get moderated to +1 so easily at Slashdot.
First, to address your claim on GNU Arch's quality, I'd like to point out that it's not meant as a correctional to CVS like SVN is -- the best description I've heard of it is as a formalization and automation of the development process that the GNU project used before Cygnus introduced networked CVS as an easier but more limited method.
One of Subversion's most important features in my mind is that of whole source patches (I think they may call them atomic patches or something). Good job SVN team (this is in all seriousness; I'd be foolish to wish harm on any F/OSS project). However, they've fallen down in the much more critical area: providing distributed development.
If CVS and SVN are the Cathedral, Arch is the Bazaar. When SCO posted their "Reasons to use SCO UNIX" list, one of the items was (paraphrased) "A single vendor" which most people criticized as being "a single point of failure" and I fail to see the difference in using a CVS or SVN archive. Witness the damage caused by Savannah getting compromised -- what if the same had happened to Sourceforge? (Arch has added GPG signed archives to address this issue.)
The freedoms held so dearly by the GNU project and the FSF are our freedom to make changes, but with centralized development tools like CVS and SVN, third party developers are second class citizens at best forced to get permission from the maintainers to make any changes -- patches must either be submitted via email or the client must ask permission to get added to the permissions list.
I don't like that.
And I'm sure many other people don't -- how many projects in our history have been forked because people had too much difficulty getting their patches into version control? Would OpenBSD have forked if Theo de Raadt could have still submitted his patches to NetBSD? Would EGCS have forked if the GCC steering committee could have gotten their patches in? Would Keith have forked X? Would XEmacs have forked FSF Emacs? The list goes on...
People don't like being treated like shit, and if you're going to treat them that way, expect them to do the same to you. Hackers are just like any other artisan -- they're proud of their work and if you treat it poorly, they consider it an insult to them. You don't necessarily need to accept someone else's patches into your own code, but you still need to respect their right to have their patches treated just the same as yours are treated (just think Voltaire as a modern day hacker: "I may not agree with what you code, but I defend to death your right to code it.")
As for the user base, aside from being self hosting, projects that are maintained using Arch include Rhythmbox, Squid, Xouvert, Y Windows (or so I'm told), and a few others (at least some other GNOME projects IIRC). GNU Emacs has added arch-tag lines to the source code to facilitate a change in the future, and the Linux source code is mirrored under Arch (a change from Linus to arch is pending *at least* some speed increases on large source trees and probably some more support/documentation).
I'd tell you to read some background on projects before making your stupid claims, but this is Slashdot so I don't know what the point is. Readers, please mod down the parent.
-jivera
Ok, So I'm confused. http://subversion.tigris.org/project_issues.html says that 'Severity is represented in the Priority field. Here is how priority numbers map to severity:
e sort=1&component=subversion&issue_status=UNCONFIRM ED&issue_status=NEW&issue_status=STARTED&issue_sta tus=REOPENED&order=issues.priority shows 5 defects with severity P1.
* P1: Prevents work from getting done, causes data loss, or BFI ("Bad First Impression" -- too embarrassing for a 1.0 release). '
Yet, http://subversion.tigris.org/issues/buglist.cgi?r
Thats kinda weird.
You've made two posts with the same apparent misconception. Subversion is not bitkeeper. Subversion is completely free. Its license is essentially MIT-ish. There's absolutely no concern by anyone that Subversion is restrictively licensed; especially when the current Linux SCS being compared to it is BitKeeper!
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
...I started using CVS yesterday. DOes that mean I need to forget everything already and start over with the new system ? Well, it looks slashdoted, so I guess I'll keep CVS for now. I'm only on page 3 of the manual anyway...
Non-Linux Penguins ?
A company I work for has a few hundred developers using Perforce. At home I've been using svn for a few months. Here's my quick comparison:
Perforce:
Pros:
- Very fast. Very, Very, Very fast.
- Stable
- Decent cross platform support
Cons:
- Commercial (but not as expensive as BK)
- Binary-only--we can't (easily) fix it.
- Windows UI is a bit inconsistent
- Requires manual checkout
- Requires server for revert, diff, etc
- Stores client state on server. Thus there are coherency issues--if you 'rm' a subtree on the client, the server still thinks the client has it, and 'p4 sync' will not refretch it. It took developers a while to grasp the need for 'p4 sync -f' in this situation.
Subversion:
Pros:
- OSS License
- More features than CVS (already covered)
- Automatic file open (you can just start editing a file in a checked out module)
- 'svn status'
- Serverless revert, diff.
- Short learning curve
- Active developer/user community
Cons:
- Berkeley DB. Data does not seem to be very portable between different library versions. Yes, you can dump and reload, but the lack of binary compatibility is lame.
- SVN Schema Changes. These also require manually dumping and reloading the repository. SVN developers claim schema changes will be rare as of 1.0. I've been through three so far... we'll see.
- Berkeley DB. 50k in text takes 2-3MB in the DB. "Fortunately" there are arcane manual tools to prune it.
- Performance. Not slow, but local svn is slower than LAN Perforce.
- Berkeley DB. Twice I had to run db_recover when svn 0.36.0 locked up and/or refused to run. Tangential evidence suggests DB 4.2 fixed the bugs. Make frequent gzip'd backups of 'svnadmin dump' and you should be OK. Also test rigorously before you deploy--this is a 1.0, after all.
So, you haven't seen http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20 Support
;)
where you can download native, non-cygwin binaries have you
Yeah, it has some nice features... and an absolutely crappy interface. Also the forced version numbering scheme and the need to have something that looks like an email address (developer@no.spam.invalid) in archive name are just brain damaged.
For the distributedness, Arch rules, but Subversion is just so much more pleasant to use and doesn't try force any particular naming and versioning schemes on me like the fascist Arch.
(ok, go ahead and mod me a troll. in truth, i havent looked at this new incarnation of cvs yet and it may be quite good, but I spent two years concurrently using and administering CVS and SourceSafe at a university and commercial environment and i must say that CVS was absolutely horrible stuff that only those who were weened on it could appreciate)
KDevelop supports Subversion natively along with CVS, Perforce, and ClearCase.
Or hey, maybe he could use a version control system with a sane security model rather than futzing about with all sorts of hacked up workarounds? Or is that too easy and obvious?
is persuade Linus to use it instead of BitKeeper.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
You seem to have completely misunderstood me. I might have been not clear enough. Of course Subversion is free software, there is absolutely no question about that and that is exactly why I would like to see it being used in Linux development which, after all, is free software itself. What I am concerned about is the very license of BitKeeper causing lots of controversy[1][2][3] with the clause preventing the development of competing products, like the very Subversion we are talking about.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
I've been using svn for years. Shortly after Sept. 11, I took a flight. The name of the Subversion book used to be "The Ultimate Guide to Subversion". I got more than a few looks while reading it in the airport!
It's called AnkhSVN.
Enjoy!
One problem I've had on every job with CVS is that, eventually, every long-running project has to support multiple versions. These invariably go off onto their own branches, and then you have whatever branching scheme for continuing development superimposed on these version maintenance branches and it ends up looking like a bunch of spreading cracks on a frozen pond threatening to swallow the whole project.
I know there's a better way to handle this than CVS allows--does subversion implement it?
sev
but have you considered the following argument: shut up.
From the mailing list:
1 .0.0.tar.gz1 .0.0.tar.bz2
Subversion 1.0.0 is ready! Grab it from:
http://subversion.tigris.org/tarballs/subversion-
http://subversion.tigris.org/tarballs/subversion-
The MD5 checksums are:
32f2c6e8c7f97587f19275c4e3219363 subversion-1.0.0.tar.gz
ee14f19960c7fa9f2640ff04acdce804 subversion-1.0.0.tar.bz2
Subversion is the work of many volunteers from around the world. It would be impossible to thank them all by name here, though they certainly deserve it. If you see a Subversion developer, documenter, or tester in the street, buy 'em a beer -- they've earned it.
Thanks also to CollabNet, which started the Subversion project and continues to pay for three (and sometimes four) full time developers.
Praise, blame, questions, and bug reports are all cheerfully accepted at
users@subversion.tigris.org.
Enjoy,
-Karl Fogel
Sorry about the formatting.
Richard is happy that Free Software (GPL'ed or not) is sold commercially, either by itself or embbeded in services, what he isn't happy about is for software that has its users submit to the author.
All software should be free as in freedom, so I completely fail to see the problem here. Popularity is a shallow goal, so you should aim for freedom for everyone, instead of popularity. If you respect your users and your software is good, popularity will likely come.
However, if popularity is your goal, you will likely start disregarding many good choices because they can be seen by some as not so popular...
Is this what the linux kernel development team uses? I know that a few years back they dumped CVS, but I thought it was for something proprietary and non-free, as in $$$$$
If your statement is really true, isn't that quite a bit constraining to linux kernel development?
This should not be a anti-BK-rant (I never used BK and can't say anything about it's qualities), but I think this would be a good argument against it. In the M$/SCO world, one expects such NDAs. But not in the Linux world.
But one big + for SVN over arch is the already existing huge number of integration tools for it.
Eclipse:subclipse.tigris.org
GUI: Rapidsvn
Windows Explorer and Visual Studio: tortoiseSVN
KDevelop3 already knows it out of the box...
and probably a bunch of others
Every version control system survives and falls with the level of third party integration and SVN is definitely already there, due to the huge number of people who simply want to replace CVS with something similar which does not have CVSs problems!
Arch maybe better, but where are the tools?
Because integration with the system security model is a sane way to do things and a good default. A jail or chroot environment is a good compromise in that it does not require a new security model and lets the OP restrict source management users from accessing the rest of the system.
[Set Cain on fire and steal his lute.]
from some online CVS documentation :
It is possible to "map" cvs-specific usernames onto system usernames (i.e., onto system login names) in the `$CVSROOT/CVSROOT/passwd' file by appending a colon and the system username after the password. For example:
Thus, someone remotely accessing the repository on `chainsaw.yard.com' with the following command:
would end up running the server under the system identity kfogel, assuming successful authentication. However, the remote user would not necessarily need to know kfogel's system password, as the `$CVSROOT/CVSROOT/passwd' file might contain a different password, used only for CVS. And as the example above indicates, it is permissible to map multiple cvs usernames onto a single system username.
while (!asleep()) sheep++
I think we need a new moderation category.
> Many of these are folks who are stuck in a bizarre recursive process of accusation and counter accusation against ....
>
> Oh, wheels-within-wheel-within -- oh just take the blue pill!
Great!
Instead of being stuck in a wheel-within-wheel-within...(infinity times) of accusation/counter accusations.
I'm now only stuck in a wheel-within-wheel-within...(infinity-minus-one times) of accusation/counter accusations.
A few more blue pills and I'll be free! (BTW, can you spare infinity-minus-fifty blue pills?;-])
If you had really read Stallman, you'd know he supports using non-copyleft for fast popularity gains when the free implementation is competing with proprietary ones. When there's only a free implementation, he (and I) supports copyleft in order to give free software a competitive advantage over proprietary one -- that's the explanation for ReadLine.
When the X Window System appeared, there was no competition whatsoever. Even now there is none that fits the bill. But there are proprietary derivations hoarded from the RI, and lots of proprietary components that makes free software life so much more difficult, esp. for RISC users. It is the same pattern that almost killed Unix BSD.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I know this is slightly off-topic, but I wonder if anyone is aware of an open-source Electronic Document Management System (EDMS). The specification for CVS/Source Control and a EDMS are very similar:
- Document profiles
- Full text indexing of all documents regardless of file type
- Combined searching of both profile and full-text index
- Integration with major software applications
- Individual document security and the ability to secure whole categories (e.g. financial information)
- Version control
- Audit trail to see who has (accessed / changed / checked-out / printed) documents
- Reporting on documents (all documents used by Joe Bloggs, all documents used within last 3 months)
- Check-in/Check-out of documents
- Local copies (Mirroring) so that you do not need a network connection (allowing laptop use)
- Web-access to all documents
I wonder if anyone knows of such a system?
There's also a (somewhat unrelated) project of the same ilk for CVS called, unsurprisingly, TortoiseCVS (different developers IIRC, same idea though, hence the similar name).
Somewhat unrelated? TortoiseSVN is a straight mod of the TortoiseCVS codebase made to work with Subversion. Yes it's different developers, but the TortoiseSVN guys got a giant head start on TortoiseSVN by using the code from TortoiseCVS. It's mentioned on both sites. I use them both, they are amazing tools.
Are there any plans for a version of cervisia that works with subversion? Or does it already?
creation science book
Try out TortoiseSVN as well. I us VS.NET, and have come to prefer doing version control through Windows Explorer.
The URL for cscvs, for those who are wondering, is http://wiki.gnuarch.org/moin.cgi/cscvs . You need to have GNU arch access to download the source code.
Evan Prodromou | evan@prodromou.name | http://evan.prodromou.name/
Subversion itself has been self-hosting with Subversion since 2001. Subversion 1.0 source is currently hosted on Subversion 0.37.
How do they compare on documentation? I have seen that subversion comes with a free whole book.
"I think this line is mostly filler"
Frankly, the one big problem I see with Subversion is that it, like many of the OSS SCM tools I see out there, has little to no sense of security. This is not a dig to the SVN guys, but how can I reccomend a tool that show so little thought with regards to security when that tool may be the only thing standing between our developers and someone sticking a backdoor/trojan/virus in a piece of code?
.02c from someone who spent the better part of a quarter trying to find a decent OSS SCM tool to replace our CVS and QVCS repositories.
From reading the svn book, the only login security I see that's really supported is HTTP Basic (I dont' see really any docs on SVN's own protocol with regards to this), which is a joke. Looking at it further I see you *could* try and use it with the various mod_auth_* modules (only the ones that work with apache2) , but only to the point where they mimic HTTP Basic.
Unless someone reworks HTTP Basic so it has concepts like account lockout, proper account management, address restrictions (actually you can mimic that with htaccess parms, but it's a PITA), and decent logging, it's not a wise choice.
Digging deeper, SVN uses db3/4 for it's storage, which again, has no idea of resource limitations or access restrictions (and doesn't handle large binaries check-ins well either).
SVN looks like a decent SCM for a really open project, but it doesn't go nearly far enough in fixing the basic problems of CVS with regards to security. The last time I broached this with the SVN guys, the response was more or less "just tunnel it over ssh". That doesn't fix the basic lack of security in the SVN design, and doesn't work with many of the popular SVN add-ons.
my
Bugs Bunny was right.
No, it doesn't.
Subversion has two different server options: svn+ssh, which does require a local Unix user account, and mod_dav_svn, which runs behind an Apache server.
mod_dav_svn is really cool. You can use any Apache authentication module to authenticate users. There's a fine-grained authorization module that allows you to create groups, and designate read and write access to individuals and groups for particular directories in the repository. You can access the repository with any web browser, and many WebDAV clients.
Very cool stuff. The main drawback is that you need Apache 2.0.48--doesn't work with anything earlier.
Open Source Solutions for Small Business Problems
Freelock Computing
My evaluation of Arch took place about two months ago and everything I said was true at that time.
That a weird word to describe arch. The original implementation consisted of a couple of new general purpose utility to add to the Unix toolbox, and a bunch of shell scripts on top of them. That is as far from monolithic as you get.
It's incorrect in that you use the words "original file" like they have special meaning, but pretty well on track.
:) As soon as the file descriptor is closed *for any reason* the space becomes usable by the OS again. "any reason" can include the program puking, the power going out, etc.
Okay. Here's basically how it works.
- When you create a file, you allocate a bunch of blocks on disk, and make a "hard link" to it. This "bunch of blocks" will be an inode, and some filesystem blocks (or block fragments). This "hard link" is just a directory entry. Also, the reference counter in the inode will be set to one.
- A directory entry is just a special file which says "okay.. this file starts here, this one starts there..."
- When you create a soft link, you're creating a file which basically says, "Hey, look at this file instead!". It is pretty much analogous to a 303 HTTP Redirect.
- When you create a hard link, you're creating another directory entry which points to the same inode as when you created the file. You also bump the reference counter.
Note that once you have a hard link, it is *indistiguishable* from the "original file".
- When you open a file, the kernel "mentally" bumps the reference counter.
- When you remove a soft link, nothing special happens, except the file containing the soft link is removed.
- When you remove a hard link ("# rm filename"), you just remove the directory entry and decrease the reference counter.
- When you close a file, the kernel "mentally" decreases the reference coutner.
- When the reference counter is zero, the file system is free to reallocate the data blocks (or block fragments) for other purposes, and the inode for another file.
Note that the open/close file behaviour is pretty important, too. This, for example, is why I like to erase temporary files as soon as create them.
If you're interested in more details w.r.t. UFS, "man -s4 fs_ufs" on a Solaris machine.
Do daemons dream of electric sleep()?
The dead-tree version is in third edition. I'm nearly done with it - I enjoy paper more than pixels for such subject matter.
See O'Reilly if you're interested..
Redundancy is good; triple redundancy is twice as good! - Me.
Stop thinking like a UNIX programmer and start thinking like a non-technical person.
What are you talking about? CVS isn't meant for non-technical persons. Never has been. It was designed as a tool for UNIX programmers.
Are there any easy-bake utilities for migrating from VSS to SVN (or CVS)? I am 50% of the non-Windows staff in my organization, so this would be a very hard sell. The plus of "no more license fees" is balanced by the minus of "it isn't from Microsoft". Switching must be seamless & painless. Yes/no?
We're talking about a version control system targeted at programmers. Why shouldn't he think like a programmer, in this context?
This is exactly my concern. There is even this question: Do you anticipate implementing a source management system in the next: [Please select] on BitKeeper's download form, where providing your real name and email address is mandatory.
Let me quote Bitkeeper issue from Linux, GNU, and freedom by Richard M. Stallman:
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Some of you may want to check out this site that discusses Subversion myths from a Subversion developer: http://www.red-bean.com/~sussman/svn-anti-fud.html
and will probably move all of them over at some point.
:-). For security purposes, the ASF wants to transition away from shell accounts and SSH/CVS, towards SVN. Now that SVN 1.0 is released, we're going to start asking projects to (voluntarily) move into SVN. At some point in the future (year?), it will become a mandate and we'll completely disable CVS and the shell accounts.
A bit more than probably
I think I misinterperted you a little, but are you being sarcastic? What do you mean?
as a snapshotting system such as CVS is inclined to do
Gah! Meant "a snapshotting system such as SVN".
It's a minimalistic issue tracker for software projects based on Wiki and Subversion (with later support for Arch and CVS planned), written in python.
Trac has browsing of Subversion repositories, viewing diffs/changesets and allows judicious hyperlinking between bug reports, commit-messages and
If you've seen cvstrac or viewcvs, you'll be familiar with the concept.
Check it out at http://trac.edgewall.com/
I'd love to see a credible source for your "slow as a scripting language" claim.
I can't provide a URL at this time, but we're talking writing a register to memory and reading again from the same memory location right back into that register. According to an article I read about Proebsting's Law (compiler technology progresses roughly 12 times more slowly than integrated circuit density, that is, about 18 years to double), most other modern compilers do at least peephole optimization (eliminating redundant store/load pairs for non-volatile variables) even on their -O0 (optimize zero) settings. Compiling each subexpression into its own independent basic block works well for debugging but not for compiling production software.
If you can't load a kernel through the BIOS boot service, that machine should never have shipped.
If a BIOS can load only vendor-signed kernels, per specification, should the machine ever have shipped?
Assuming that I can open a hole in the firewall long enough to allow SDK Update to run through Microsoft Internet Explorer, does the compiler included with the Platform SDK include even the most basic optimizer? I've read that Microsoft has been distributing C++ compilers without even a peephole optimizer.
I have the standard edition (Version 6)
I've already explained why I find the standard version of MSVC unacceptable. I'd rather run a UNIX app in Cygwin than run a Windows app built with a non-optimizing compiler.
Sure that's 100 more than downloading a Linux distro and getting everything for free
If I were to install GNU/Linux as a dual-boot just for developing projects that use Subversion or Arch, I'd have to buy at least a new video card (the Radeon driver included with Mandrake 9.2 didn't work with my Radeon 9000 card, and Knoppix ran unacceptably slowly using the default unaccelerated driver) and a new hard drive (mine's NTFS and near full). If I were to switch to GNU/Linux exclusively, I'd need a new scanner (Microtek Scanmaker 4800 series is listed in SANE as unsupported), and I'd lose the time (which is money) that I've spent on learning the ins and outs of the Windows applications that I have.
Wrong. Stallman wants to impell PROPRIETARY towards freedom for their users, since readline is so useful, it has made some sofware become GPL because of it.
No, producing GPL'ed libraries compels every non-GPL developer to GPL their code (so they can use that library). There is no exception for (say) BSD developers and you can hardly call them proprietary (using caps doesn't change that).
All software should be free as in freedom, so I completely fail to see the problem here.
That's your personal conviction, but I want to leave that choice up to consumers & developers. As a developer, I may choose a less restrictive license than the GPL because it suits my goals better. I don't particular fancy another argument over why Free is better than free, but it helps if you at least appreciate that other people may not share your views on this matter.
Popularity is a shallow goal
No, it isn't. Many great things can only be achieved by popularity. Democracy can only work if most people are allowed to vote and do so. A well educated populace is also highly desired and can only be reached by having a 'popular' education system. I also don't think that RMS considers popularity something beneath contempt, since he would be happy to have all the software GPL'ed.
Perhaps you wanted to point out that popularity should never be the end goal, but it never is. There is always some underlying reason, in the case of BSD-like licenses:
- Spreading good code
- Popularizing a certain standard, concept, etc.
- More people contribute
- Personal satisfaction
These are all perfectly valid reasons. There is nothing shallow about any of them.
interesting food for thought... those goals might include something like allowing some to take freedom from their users?
Popularity is something you might deserve upon your good deeds, and that might help you do more, but never as a goal.
You're mixing apple with oranges. Are trying to deliberatly influence others into thinking I'm agains Democracy? I seriously hope not.
People don't vote because they are popular but because it's their right to participate in Democracy, and voting on THAT guy only because he is popular is a perversion of Democracy. You should vote on the guy who you think represents your interests best. Your problem is that you confuse goal with reward.
Stallman's goal: freedom for _all_ (yes, all, that's why GPL is so important), not just those who got the code with a Free license like BSD.
His reward: popularity for being one of the most important freedom fighters of nowadays.
Oh really? Let's look at your examples:
- Spreading good code
Spreading -> popularity
- Popularizing a certain standard, concept, etc.
Popularizing -> popularity
- More people contribute
More people -> popularity
- Personal satisfaction
If your goal is popularity, of course you'll be satisfied, all you said were goals of popularity, and none of doing something good which results in popularity...
BSD style is friendly towards proprietary software[...]those goals might include something like allowing some to take freedom from their users?
Your logic is flawed, since it also be used to promote a police state. Due process of law, public trials and no torture coerced confessions can all hinder the prosecution of criminals (and are thus 'friendly' towards criminals). However, I feel that the downsides of a police state are too great.
Proprietary code can lead to abuse, but there are also a great many closed source applications with which I have no problem. I also feel that the GPL is far from perfect for every situation and that some software would never be build if the GPL was the only option. So I simply don't think that the abuse of software users is important enough to accept these downsides.
You're mixing apple with oranges. Are trying to deliberatly influence others into thinking I'm agains Democracy? I seriously hope not.
No, the point is that popularity can be immensely important. In that regard, popularity can be a very important goal if you want to achieve something (assuming a hierarchy of goals).
People don't vote because they are popular but because it's their right to participate in Democracy, and voting on THAT guy only because he is popular is a perversion of Democracy. You should vote on the guy who you think represents your interests best.
That's not what I meant. My point is that a democracy only works if voting is popular. It cannot work if only an elite few bother or are able to vote. In the context of democracy, popularity is not shallow.
Your problem is that you confuse goal with reward. Stallman's goal: freedom for _all_ (yes, all, that's why GPL is so important), not just those who got the code with a Free license like BSD.
His reward: popularity for being one of the most important freedom fighters of nowadays.
Every reward can be a goal. I can't judge RMS' ego, but personal popularity is desired by many, so he might see that as one of his goals. But anyway, that was not the kind of popularity I was talking about. I was talking about popularizing the GPL, which seems to be a valid goal to you.
Oh really? Let's look at your examples:
- Spreading good code
Spreading -> popularity
- Popularizing a certain standard, concept, etc.
Popularizing -> popularity
- More people contribute
More people -> popularity
- Personal satisfaction
If your goal is popularity, of course you'll be satisfied, all you said were goals of popularity, and none of doing something good which results in popularity...
'Spreading good code' uses the popularity of software components to increase the quality of software. Popularity is a means.
'Popularizing a certain standard, concept, etc' is what you do when you want people to use something great. A good example is the TCP/IP-stack. Once upon a time that was new and a BSD'd TCP/IP-stack made it easier for that standard to spread. The end-goal might be to allow computers to communicate. Popularizing TCP/IP is a means to reach that goal.
'More people contribute' to improve the product in one way or another. The end-goal is that the value of the product increases. An example is the open sourcing of Linux, Linus could never have done all the work himself to get Linux to where it is today. Popularity is a means to get these contributions.
'Personal satisfaction' is especially important to open source developers who work in their spare time. Helping people seems like a worthy goal to me and the more popular your software is, the happier you may feel about your work (since you help more people).
Popularity is always the means to reach another goal in these cases.
all you said were goals of popularity, and none of doing something good which results in popularity...
I hope that you changed your mind about that.
It's extremely important if you use Visual Studio.NET to get the VS.NET edition of TortoiseSVN. VS.NET hates the ".SVN" folders that TortoiseSVN creates, so the VS.NET version of TortoiseSVN uses "_SVN" folders instead.
I've been using TortoiseSVN and Subversion RC1 for a while now and I can't really fault it... Way less headaches than I had with working with the mature CVS system!
I've setup SVN to replace CVS at 2 companies now, and they're both very happy.
...... CVS
Here's what I say:
* Just leave the old CVS data where it is, you can always use your old methods to get hold of it...
* The most precise record of how the past (which was recorded in CVS) was is in
* When starting a new project --- use subversion, and move the components required for that project from CVS to subversion --- minimum work, maximum benefit
SLOGEN [ http://ungdomshus.nu : Sebastian cover music]
Also, because it isn't filesystem-backed, there is no need to have one system account per SVN account.
Bogus. Arch is filesystem-backed, but if it's used through WebDAV, Apache's user authentication can be used there too.
The biggest downside to arch is user interface and documentation. I hate to say it, but it's true. Obscure error messages is one of arch's biggest problems, and command names and syntax are sometimes not consistent. Focus thus far has been on functionality; user interface cleanups will probably start in earnest after GNU Arch 1.2 is released, which shouldn't be too far off.
There is, however, a fairly decent Arch tutorial called "arch meets Hello World", and if you like wikis, there is a more or less official GNU Arch wiki. (Even if you don't like wikis, there's good information here.) Each tla command will give you short usage if you specify --help as an option, and more info if you give -H.
Ah, I didn't know about mingw. Well, that's too bad.
... ^^; )
As a point of curiosity, what if that installer shipped the arch binary and cygwin.dll, but just didn't tell you? That's really all arch needs. Since all you'd have to do is ship the binary, install it in (say) C:\tla, and put the Cygwin DLL also in C:\tla, if an installer did that for you, would that be enough?
(tla works fine for non-distributed Open Source projects too, speaking from experience
That wasn't so bad, was it?
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent