Re the NTFS thing, see Captive. Sure, it's not going to be included in any mainstream distribution soon -- but it's still a damn nifty piece of software.
Having said that, I found that people in London were noticeably friendlier than folks here in the U.S.
Just curious: Where in the US? Are you just discussing back east (to which I haven't been)?
I've noticed that folks in some parts of northern California are substantially friendlier than those in the bay area, for instance; and folks in Austin, TX are friendlier than... well, most of the rest of the country (and likewise fare well as opposed to the rest of the state).
The smart people know that if they will serve on a jury, they will lose their jobs.
Not if it's a job with an employer worth working for. Firing someone for serving on a jury is illegal, not to mention unethical and (typically) a bad business decision.
If you'd read the subthread, by "be gentle" I meant (among other things) "please seed after downloading"; the same machine that's running the tracker is presently seeding.
Oh -- and now that I think of it, the primary way to be gentle (or at least _nice_) when doing a BT download is to leave BT open and seed for a while after your download's done.
Arch *does* solve this problem, but that it does so is pretty much orthogonal to the atomic changeset commit support.
The way Arch works, each file is tagged with an arch-id. This can be included in the file in tagline mode (with a comment such as "# arch-id: ", in an external file, etc. Whenever a file is moved, this is simply recognized by Arch as "the file with tag $FOO is moved to location $BAR"; likewise, modifications to files are represented as "the file with tag $FOO has patch $BAR applied". This means, for instance, that you can merge a patch which modifies src/myprog.c, and a patch that renames it to src/main.c, and the two patches will be correctly composited whichever order you merge them in.
I was just rereading bits of this thread, and have a simple question: What is POSIX if not an OS abstraction layer? Isn't any sort of need to add additional abstraction on top of it indicative of breakage?
And btw, there's a native win32 port of tla; see here.
I have a largish tree that's in dire need of some revision control. If things go as planned, it will be developed in multiple branches and will have automated remote checkouts (maybe even automated unit testing).
Working with multiple branches in modern source control systems is a breath of fresh air if you've had the misfortune to do it in CVS previously; I'm sure you'll be pleased.
I've mentioned this in a few other posts, but if you want your unit tests to pass before a checkin is allowed, you might want to use arch-pqm (previously tla-pqm but recently generalized to work with the/other/ arch fork, and thus renamed) to manage your official archive rather than letting users commit directly; it permits you to define a precommit hook (which can validate, for instance, that the automated tests pass) which runs before accepting a merge request. It's pretty trivial to manage specific branches this way, so you can set individual policy easily -- indeed, arch is pretty good about that in general. (Example set of policy that would be fairly straightforward to create: "the --dev branch can be committed to by any developer with a valid user account as long as the test suite passes, or the dev lead under any conditions whatsoever; the --qa-accepted branch can be committed to by any member of the QA staff but nobody else; the --release branch can be committed to by deployment staff", and so forth along those lines).
Yup. Sorry for coming with something that was a bit of a non sequiteur -- I only track the Arch list, and it's in our own context that we'd decided that keyword expansion was a Bad Thing. That said, hopefully it manages to bear at least somewhat on what you were discussing. Sure, SVN doesn't have the optimizations I mentioned -- but the general "there's better ways to do this" objection probably still applies there.
That's quite a lot of work. It means making optimizations optional (ie. having a separate, nonoptimized version of the same algorithms). Furthermore, cases like FreeBSD (projects w/ large numbers of files) are *exactly* why the performance optimizations were implemented in the first place. Adding support for taking them out for precisely the same projects seems... well, perverse.
And frankly -- even if someone did write this feature, Tom has said up front that he wouldn't accept it into Arch.
All that said -- adding documentation on "why arch doesn't need user-defined tags" to the wiki, at a minimum, would probably be useful.
Okay, I can grant that. One ongoing development item with Arch is development of a smart server; this will permit queries like "provide the set of all changes between patch-3 and patch-50" to return a single stream with redundant data permitted. That said, I still don't think depending on a smart server is a good idea, at least in a Free Software context: there's a whole lot to be said for being able to use (for instance) your Savannah account to host at Arch repository, even if the Savannah admins aren't willing to install any software specifically to support it; further, a dumb-server-based hosting service isn't going to have the same kinds of scalability problems SourceForge has had lately with CVS.
(I'm also unconvinced as to the value of using WebDAV for such a smart server protocol rather than building it ground-up, but that's a topic for a whole different discussion).
I can't comment on how to do this with Subversion, but I can certainly comment on how it works in Arch.
Every file in Arch has a globally unique, unchanging ID tag. This tag persists between moves and copies -- even between files in completely different repositories. Arch projects also have patchlogs, which track which patches have (and have not) been applied. Patchlogs aren't per-file, but global to the repository -- just as changesets themselves aren't per-file, but may include any number of modifications to the repository's contents.
As for "what version a particular file is" in whichever tree, that entire concept is a bit specific to CVS. Subversion doesn't version files; it snapshots trees. Arch doesn't version files; it manages changesets. As for determining which patches have been applied, the patch logs cover that -- but there really is no concept of a file version at all.
As for managing FreeBSD-specific features, this is easy with Arch. Just merge in the feature; when OpenBSD pulls the tree, they notice that it includes a patch they don't want (or can't accept), so they back out the patch but keep its patchlog (indicating that they don't want the revision control system to try remerging it later)... and volia! Arch knows that OpenBSD doesn't want this FreeBSD-specific patch, but will potentially try to merge other changes on request.
As for cvsup and company, as before, Arch has all that functionality built-in.
Arch has "patchlog" support to track which patches have been applied to a repository; instead of determining what the current version is (as a snapshotting system such as CVS is inclined to do), it tracks what patches have been applied to get there. When one merges files between projects (as between the various BSDs) with Arch, one merges the patchlogs as well, and the file's ID tags as well. This is sufficient to permit Arch changesets made against (say) NetBSD apply to OpenBSD, if OpenBSD has files with the same tags as those that were modified in NetBSD and the patches still apply cleanly.
Unlike the user-defined tags that are mentioned here, Arch ID tags don't change -- they're typically UUIDs, static for a file's lifetime and globally unique; this means they aren't incompatible with Arch's performance and space optimizations in the same way that tags which get expanded and "shrunk down" during checkin and checkout are.
Modifying files on checkout/checkin is incompatible with some of Arch's most interesting (and very effective) performance and space optimiziations, some of which are available in no other source control system existing. Creating working directories as hardlink trees out of the revision library is suddenly impossible; checking inode signatures to determine quickly which files changed becomes more complex; and these tags simply don't do anything useful that Arch's patchlog approach can't or won't.
I sing of the broken architecture is also the huge amount of commands, born to fix Arch deficiencies. Too bad someone does not pickup detached developement and change-set oriented ideas and does not re-implement the thing in a sane way
Huh?
Show me an Arch command, and I'll show you a good reason for having it. The only exceptions that comes to mind is perhaps make-{category,branch,version} (which are now replaced by archive-setup functionality and exist pretty much strictly as legacy code), and the abrowse/rbrowse distinction (which will go away after rbrowse finishes taking over the world and abrowse is deprecated and removed). Those are just UI issues, though; I don't see anything here that bears on Arch's core design.
I didn't say that it works without dependencies, I said that it's been fully converted to C. Stop putting words in my mouth.
Why does the SCM care about the OS? It doesn't, really, beyond caring about POSIX compliance. Slap WSU on WinXP and it's suddenly on a POSIX compliant OS, and reportedly functions perfectly. (By the way, I said "WSU", not "Cygwin"; listen carefully, please; Cygwin is not required).
As for the Cygwin branch, see here. Is it a hack? Sure. Does it work? Reportedly so (and yes, its archives are compatible with the UNIX version).
Any workaround would effectively be guesswork: "These happened around the same time with the same comment on commit, so they must be part of the same changeset". Then to preserve your record of what the file state is that you tested to work you need to tag everything, which means modifying every single,v file in the repository and is ridiculously slow when one has a 30,000 file repository (as I do at work), not to mentioning making every single file a bit bigger (which adds up when one's doing daily builds and tagging each one).
In short: Persueding CVS to Do The Right Thing is a hack (and thus time-consuming and error-prone, as all hacks are when one tries to polish them enough to work in a commercial environment), whereas newer tools are built for it.
Slashdot Mirror
Re the NTFS thing, see Captive. Sure, it's not going to be included in any mainstream distribution soon -- but it's still a damn nifty piece of software.
NOW, I can say THANK GOODNESS no more lockups in Fedora from DriverLoader BS
Ya know, I've been using ndiswrapper for quite some time, and it hasn't crashed my machine yet.
I've noticed that folks in some parts of northern California are substantially friendlier than those in the bay area, for instance; and folks in Austin, TX are friendlier than... well, most of the rest of the country (and likewise fare well as opposed to the rest of the state).
The smart people know that if they will serve on a jury, they will lose their jobs.
Not if it's a job with an employer worth working for. Firing someone for serving on a jury is illegal, not to mention unethical and (typically) a bad business decision.
Really, what does this do for them legally?
It certainly can't help, and may hurt (say that they were found to have sold EV1 a license they knew at the time to be worthless).
Couldn't they take SCO to the cleaners if/when SCO loses and this "license" is proven not to be a requirement?
The text of the contract says pretty clearly that you don't have much recourse if/when it turns out to be worthless.
Being Not A Lawyer, I can't really comment on how enforceable this clause is.
Sorry, all, but as it's come to my attention that Harvard objects to 3rd-party distribution of this speech, I'm taking the tracker down now.
If you'd read the subthread, by "be gentle" I meant (among other things) "please seed after downloading"; the same machine that's running the tracker is presently seeding.
Oh -- and now that I think of it, the primary way to be gentle (or at least _nice_) when doing a BT download is to leave BT open and seed for a while after your download's done.
Poking around at other items on the server's webspace, maybe.
Having listened to the speech, I assure 'yall it's much better listened to than read.
I've put together a BitTorrent share with a Speex encoding of his speech. Please be gentle.
Arch *does* solve this problem, but that it does so is pretty much orthogonal to the atomic changeset commit support.
The way Arch works, each file is tagged with an arch-id. This can be included in the file in tagline mode (with a comment such as "# arch-id: ", in an external file, etc. Whenever a file is moved, this is simply recognized by Arch as "the file with tag $FOO is moved to location $BAR"; likewise, modifications to files are represented as "the file with tag $FOO has patch $BAR applied". This means, for instance, that you can merge a patch which modifies src/myprog.c, and a patch that renames it to src/main.c, and the two patches will be correctly composited whichever order you merge them in.
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.
I was just rereading bits of this thread, and have a simple question: What is POSIX if not an OS abstraction layer? Isn't any sort of need to add additional abstraction on top of it indicative of breakage?
And btw, there's a native win32 port of tla; see here.
I've mentioned this in a few other posts, but if you want your unit tests to pass before a checkin is allowed, you might want to use arch-pqm (previously tla-pqm but recently generalized to work with the
Yup. Sorry for coming with something that was a bit of a non sequiteur -- I only track the Arch list, and it's in our own context that we'd decided that keyword expansion was a Bad Thing. That said, hopefully it manages to bear at least somewhat on what you were discussing. Sure, SVN doesn't have the optimizations I mentioned -- but the general "there's better ways to do this" objection probably still applies there.
That's quite a lot of work. It means making optimizations optional (ie. having a separate, nonoptimized version of the same algorithms). Furthermore, cases like FreeBSD (projects w/ large numbers of files) are *exactly* why the performance optimizations were implemented in the first place. Adding support for taking them out for precisely the same projects seems... well, perverse.
And frankly -- even if someone did write this feature, Tom has said up front that he wouldn't accept it into Arch.
All that said -- adding documentation on "why arch doesn't need user-defined tags" to the wiki, at a minimum, would probably be useful.
as a snapshotting system such as CVS is inclined to do
Gah! Meant "a snapshotting system such as SVN".
I only meant more extensible than without.
Okay, I can grant that. One ongoing development item with Arch is development of a smart server; this will permit queries like "provide the set of all changes between patch-3 and patch-50" to return a single stream with redundant data permitted. That said, I still don't think depending on a smart server is a good idea, at least in a Free Software context: there's a whole lot to be said for being able to use (for instance) your Savannah account to host at Arch repository, even if the Savannah admins aren't willing to install any software specifically to support it; further, a dumb-server-based hosting service isn't going to have the same kinds of scalability problems SourceForge has had lately with CVS.
(I'm also unconvinced as to the value of using WebDAV for such a smart server protocol rather than building it ground-up, but that's a topic for a whole different discussion).
I can't comment on how to do this with Subversion, but I can certainly comment on how it works in Arch.
Every file in Arch has a globally unique, unchanging ID tag. This tag persists between moves and copies -- even between files in completely different repositories. Arch projects also have patchlogs, which track which patches have (and have not) been applied. Patchlogs aren't per-file, but global to the repository -- just as changesets themselves aren't per-file, but may include any number of modifications to the repository's contents.
As for "what version a particular file is" in whichever tree, that entire concept is a bit specific to CVS. Subversion doesn't version files; it snapshots trees. Arch doesn't version files; it manages changesets. As for determining which patches have been applied, the patch logs cover that -- but there really is no concept of a file version at all.
As for managing FreeBSD-specific features, this is easy with Arch. Just merge in the feature; when OpenBSD pulls the tree, they notice that it includes a patch they don't want (or can't accept), so they back out the patch but keep its patchlog (indicating that they don't want the revision control system to try remerging it later)... and volia! Arch knows that OpenBSD doesn't want this FreeBSD-specific patch, but will potentially try to merge other changes on request.
As for cvsup and company, as before, Arch has all that functionality built-in.
Question adequtely answered?
Arch has "patchlog" support to track which patches have been applied to a repository; instead of determining what the current version is (as a snapshotting system such as CVS is inclined to do), it tracks what patches have been applied to get there. When one merges files between projects (as between the various BSDs) with Arch, one merges the patchlogs as well, and the file's ID tags as well. This is sufficient to permit Arch changesets made against (say) NetBSD apply to OpenBSD, if OpenBSD has files with the same tags as those that were modified in NetBSD and the patches still apply cleanly.
Unlike the user-defined tags that are mentioned here, Arch ID tags don't change -- they're typically UUIDs, static for a file's lifetime and globally unique; this means they aren't incompatible with Arch's performance and space optimizations in the same way that tags which get expanded and "shrunk down" during checkin and checkout are.
Modifying files on checkout/checkin is incompatible with some of Arch's most interesting (and very effective) performance and space optimiziations, some of which are available in no other source control system existing. Creating working directories as hardlink trees out of the revision library is suddenly impossible; checking inode signatures to determine quickly which files changed becomes more complex; and these tags simply don't do anything useful that Arch's patchlog approach can't or won't.
Strong enough reason?
I sing of the broken architecture is also the huge amount of commands, born to fix Arch deficiencies. Too bad someone does not pickup detached developement and change-set oriented ideas and does not re-implement the thing in a sane way
Huh?
Show me an Arch command, and I'll show you a good reason for having it. The only exceptions that comes to mind is perhaps make-{category,branch,version} (which are now replaced by archive-setup functionality and exist pretty much strictly as legacy code), and the abrowse/rbrowse distinction (which will go away after rbrowse finishes taking over the world and abrowse is deprecated and removed). Those are just UI issues, though; I don't see anything here that bears on Arch's core design.
I didn't say that it works without dependencies, I said that it's been fully converted to C. Stop putting words in my mouth.
Why does the SCM care about the OS? It doesn't, really, beyond caring about POSIX compliance. Slap WSU on WinXP and it's suddenly on a POSIX compliant OS, and reportedly functions perfectly. (By the way, I said "WSU", not "Cygwin"; listen carefully, please; Cygwin is not required).
As for the Cygwin branch, see here. Is it a hack? Sure. Does it work? Reportedly so (and yes, its archives are compatible with the UNIX version).
But all the better to avoid the tweaking, no?
,v file in the repository and is ridiculously slow when one has a 30,000 file repository (as I do at work), not to mentioning making every single file a bit bigger (which adds up when one's doing daily builds and tagging each one).
Any workaround would effectively be guesswork: "These happened around the same time with the same comment on commit, so they must be part of the same changeset". Then to preserve your record of what the file state is that you tested to work you need to tag everything, which means modifying every single
In short: Persueding CVS to Do The Right Thing is a hack (and thus time-consuming and error-prone, as all hacks are when one tries to polish them enough to work in a commercial environment), whereas newer tools are built for it.