There is one single "mainline" archive, which individual developers tag from into their own archives. Then they just work in their own archive, periodically pushing and pulling changes to the mainline one.
No it's not. It's a tool for creating read-only copies of other archives. People who star-merge from other archives do commonly archive-mirror them, though, since it's much faster to work against the copy on your disk than one on some random webserver.
Regarding the rest of your post, why don't you just have multiple archives, and mirror each one to a bunch of places?
Lord references the poor merging support a few times, but fails to actually detail a complaint.
It's a shitty little online article, there's lots of explanations of this out there for people who care: basically, arch branches consist of an ordered list of changesets. The first one says "I'm branched revision $foo over there ->". Each one after that is numbered. This makes it simple to refer to any revision in any branch. "Merging" branches in arch consists of applying changesets from one branch to another. Since each one has a particular name, it's easy for each branch to keep a list of what changesets it contains. Thus, when you merge those same branches again, tla sees "Oh, we already have revisions 1..50 from that branch, let's only get 51+". In subversion and CVS you have to keep track yourself of what you've merged; in arch you just do "tla star-merge name-of-that-other-branch".
1)Branching: svn doesn't copy the entire tree - making a branch is instantaneous, lightweight operation.
This isn't what time is talking about; that's just a space optimisation. His point is that in subversion a "branch" is stored the same as a "copy", when they are sematically quite different things. I've noticed some of the core-ish svn devs saying that they want to change this at some point.
You are right that the special case where there is a central repository, everything is simple and peachy. But arch could IMHO do better than that, and make it simple and peachy even without a central repository, e.g. by tracking what change sets has been applied.
Arch does already track which changesets have been applied. It doesn't use this knowledge in the complicated manner that you suggest, however, since there are other requirements that need to be satisfied for this to work. "pure-merge" is the keyword here.
Specifically, you have to do out of tree builds or constant distcleans because arch assumes every file that gets created should be checked in, meaning there's a 1:1 mapping between the checkout directory and the repository by default.
Set "untagged-source precious" in the tagging-methods file. Yes, the default sucks for some people, but arch will work either way.
More like it is the easy way out of a lot of the tricky details with file renames and removals for the arch developers.
Erm, no, now you're just showing your cluelessness. Encouraging out-of-tree builds has nothing at all to do with renames, moves, or any other version control feature. If you build in tree, you will have NO problems at all with any of the things you mention here.
There's no Windows/OS X integration or even clients.
tla runs fine on OS X, as long as you have GNU diff, tar and patch. The windows port is seems to be working fine, albeit slowly. For all the whining about the lack of a Windows port, there's amazingly few actual contributors.
For "integration", I assume you mean something like Tortoise{SVN,CVS}? Indeed, no one has written one of them yet.
Easy to make a private branch of a repository which you do not have access to
Well, you do need *read* access to it:-P
Supposedly good merge mechanism
It's not just "supposed", it actually does work very well in practice. Most of the time you just run "star-merge" against someone else's branch and it Just Works, pulling in only the unmerged changes.
Revisions are stored as simple changesets (patches) with only tarring and bzip2'ing.
yeah, but gzip'd.
It's very slow. When working from a local repository, it feel roughly like cvs on a public mirror.
Hmmmm...I haven't noticed this. I'm using a greedy revision library, and things like "commit" and "changes" take < one second on my smallish trees...if arch is constructing pristine trees all over the place, though, then, yes, it can be fucking slow. More a case of non-optimal defaults, IMO.
generates insanely long name.
Which filenames are being generated? The only ones I can think of that are generated in normal use are the log filenames, but you can name them however you like.
To use safely, you have to know some graph theory.
No you don't. If you mean "for star-merge to work correctly, everyone needs to only merge from the hub", then I don't think telling users "only merge to and from this central archive <here>" is unreasonable or particularily confusing.
And it's got some horrifying naming conventions: "tla--devo--1.3"
I dunno...it seemed really fucking annoying when I started using arch, but now it just seems like a sensible way to organise trees. If you don't like it, just use <software-name>--mainline--0 for everything and ignore it.
"{arch}", "++default-version", ",,inode-sigs"
{arch} my be annoying, but the other two files are only found inside {arch}, away from mere mortals.
"Win32 is for lusrs!"
I've never seen anyone say this on the list. There is a general antipathy to Windows, yes, because a) all the core arch people use Unix and have no personal interest in a Windows port, and b) Window's deficiencies make porting a highly annoying task. Also, there are at least 3 different porting efforts underway, at least one of which is usable. Slow, but usable. If you care that much, why don't you help fix it?
Well, perhaps on Intel, but I have 3d acceleration on my ibook g4 (with an ati 9200) with Free drivers while people with nvidia cards have only the 2-d-only nv driver.
* versioned file renaming (simple, but CVS doesn't) * symlink versioning (nto essential, but handy sometimes, and something svn|cvs doesn't do) * whole-tree changesets (commit multiple files at once) * smarter merging. it won't try to merge changes again and again as svn or cvs would. * (optional) distributed archives. all the arch developer's have their *own* archive and branches of the main arch source tree, to which they make their own changes. you can have everyone commit to a single archive if you prefer, too. * signed revisions. arch can sign (with gpg) every change made to an archive, so other people can verify who actually made a change. * archives can be made available to others via a variety of protocols, including http and ftp. yes, you can host a arch archive on cheap webspace somewhere, or in your ~/public_html/.
As far as I know, BK doesn't do the last two, but does the rest. On the other hand, BK does handle some less common patch-flows better than arch does.
Arch does need more tools around it, but the basics are there. There are 3 web-based viewer things for it,
See, people who've only used CVS and Subversion just don't understand why subversion will never be suitable for this.
Imagine if the kernel was in subversion, and you wanted to make a change. You'd check it out and change it, make a diff and send it to the list. uh, yay, it's just like working with tarballs. But, if it was in Arch or BK, you'd make your own *local* branch on your machine, make whatever changes you like in it, commit to it (offline if you like, since the archive is on YOUR machine), move files around, etc, etc. When you're done, you merge the changes Linus has made in his tree into yours (so he has less merging to do), and tell him where your archive is hosted (arch can serve your archives to other people via plain http/ftp/webdav, BK has it's own daemon, aiui).
Oh yes, and how do you merge linus's changes into your tree? "tla star-merge <name-of-linus-branch>". No fucking around finding what you've merged before, arch keeps track of that for you. BK does the same.
2.) it has exec-shield stack protection enabled by default but its less secure than your precious debian who got owned last month right? if they used exec-shiled that brk() exploit would have failed (yes i know debian will have it soon, thank ingo who works at redhat for that).
Uh, no. None of the Linux security patches would have protected the Debian systems from this attack. Not SELinux, not GRSecurity, not ExecShield. If it had been a Fedora system, it would have been 0wned just the same.
Slashdot Mirror
and by "encrypted" do they mean "we're idiots and stored something other than a salt + hash of the passwords"?
> Science as a system proves and then verifies proofs.
eh, science doesn't have the ability to prove anything. all scientists can do is produce plausible sounding theories that match current observations.
ath5k works great under 2.6.29, with wpa2 (on the 8.9" Aspire One).
I'm not sure what you mean by a "pivot" branch
There is one single "mainline" archive, which individual developers tag from into their own archives. Then they just work in their own archive, periodically pushing and pulling changes to the mainline one.
However, he gives no details.
It's an non-technical article. If you want to know more: here and here.
archive-mirrors is a tool for star merges.
No it's not. It's a tool for creating read-only copies of other archives. People who star-merge from other archives do commonly archive-mirror them, though, since it's much faster to work against the copy on your disk than one on some random webserver.
Regarding the rest of your post, why don't you just have multiple archives, and mirror each one to a bunch of places?
Lord references the poor merging support a few times, but fails to actually detail a complaint.
It's a shitty little online article, there's lots of explanations of this out there for people who care: basically, arch branches consist of an ordered list of changesets. The first one says "I'm branched revision $foo over there ->". Each one after that is numbered. This makes it simple to refer to any revision in any branch. "Merging" branches in arch consists of applying changesets from one branch to another. Since each one has a particular name, it's easy for each branch to keep a list of what changesets it contains. Thus, when you merge those same branches again, tla sees "Oh, we already have revisions 1..50 from that branch, let's only get 51+". In subversion and CVS you have to keep track yourself of what you've merged; in arch you just do "tla star-merge name-of-that-other-branch".
(yes, this is oversimplified)
cd ~/bin ; ln -s `which tla` anonymous_cowards_arch
1. Requires that you use files named according to its conventions, not those of your software.
For example? Arch doesn't care what you call your files, but (by default), it will whinge about some things. Changes the defaults and move on.
2. Falls over on filenames with spaces in.
Fixed in 1.2.1.
1)Branching: svn doesn't copy the entire tree - making a branch is instantaneous, lightweight operation.
This isn't what time is talking about; that's just a space optimisation. His point is that in subversion a "branch" is stored the same as a "copy", when they are sematically quite different things. I've noticed some of the core-ish svn devs saying that they want to change this at some point.
Does it run over SSH ?. Does it support Solaris 2.9 ?. (two important requirements for me).
It runs over ssh version 2, via the sftp subsystem.
*) Rsync Mirroring
You can mirror arch repositories using rsync, or arch's internal mirroring support.
*) Symlinks in CVS
If you mean version symlinks, arch does this. IF you mean using symlinsk to build trees up out various subtrees, arch does this too using "configs".
You are right that the special case where there is a central repository, everything is simple and peachy. But arch could IMHO do better than that, and make it simple and peachy even without a central repository, e.g. by tracking what change sets has been applied.
Arch does already track which changesets have been applied. It doesn't use this knowledge in the complicated manner that you suggest, however, since there are other requirements that need to be satisfied for this to work. "pure-merge" is the keyword here.
Specifically, you have to do out of tree builds or constant distcleans because arch assumes every file that gets created should be checked in, meaning there's a 1:1 mapping between the checkout directory and the repository by default.
Set "untagged-source precious" in the tagging-methods file. Yes, the default sucks for some people, but arch will work either way.
More like it is the easy way out of a lot of the tricky details with file renames and removals for the arch developers.
Erm, no, now you're just showing your cluelessness. Encouraging out-of-tree builds has nothing at all to do with renames, moves, or any other version control feature. If you build in tree, you will have NO problems at all with any of the things you mention here.
There's no Windows/OS X integration or even clients.
tla runs fine on OS X, as long as you have GNU diff, tar and patch. The windows port is seems to be working fine, albeit slowly. For all the whining about the lack of a Windows port, there's amazingly few actual contributors.
For "integration", I assume you mean something like Tortoise{SVN,CVS}? Indeed, no one has written one of them yet.
Easy to make a private branch of a repository which you do not have access to
:-P
Well, you do need *read* access to it
Supposedly good merge mechanism
It's not just "supposed", it actually does work very well in practice. Most of the time you just run "star-merge" against someone else's branch and it Just Works, pulling in only the unmerged changes.
Revisions are stored as simple changesets (patches) with only tarring and bzip2'ing.
yeah, but gzip'd.
It's very slow. When working from a local repository, it feel roughly like cvs on a public mirror.
Hmmmm...I haven't noticed this. I'm using a greedy revision library, and things like "commit" and "changes" take < one second on my smallish trees...if arch is constructing pristine trees all over the place, though, then, yes, it can be fucking slow. More a case of non-optimal defaults, IMO.
generates insanely long name.
Which filenames are being generated? The only ones I can think of that are generated in normal use are the log filenames, but you can name them however you like.
To use safely, you have to know some graph theory.
No you don't. If you mean "for star-merge to work correctly, everyone needs to only merge from the hub", then I don't think telling users "only merge to and from this central archive <here>" is unreasonable or particularily confusing.
And it's got some horrifying naming conventions: "tla--devo--1.3"
I dunno...it seemed really fucking annoying when I started using arch, but now it just seems like a sensible way to organise trees. If you don't like it, just use <software-name>--mainline--0 for everything and ignore it.
"{arch}", "++default-version", ",,inode-sigs"
{arch} my be annoying, but the other two files are only found inside {arch}, away from mere mortals.
"Win32 is for lusrs!"
I've never seen anyone say this on the list. There is a general antipathy to Windows, yes, because a) all the core arch people use Unix and have no personal interest in a Windows port, and b) Window's deficiencies make porting a highly annoying task. Also, there are at least 3 different porting efforts underway, at least one of which is usable. Slow, but usable. If you care that much, why don't you help fix it?
[snip whining]
http://repose.cx/ArchPrimer.html
Well, perhaps on Intel, but I have 3d acceleration on my ibook g4 (with an ati 9200) with Free drivers while people with nvidia cards have only the 2-d-only nv driver.
Depends on your distro. PPC is never more than a day behind than x86 in Debian, and is the second-most popular release Debian architecture.
Arch provides:
* versioned file renaming (simple, but CVS doesn't)
* symlink versioning (nto essential, but handy sometimes, and something svn|cvs doesn't do)
* whole-tree changesets (commit multiple files at once)
* smarter merging. it won't try to merge changes again and again as svn or cvs would.
* (optional) distributed archives. all the arch developer's have their *own* archive and branches of the main arch source tree, to which they make their own changes. you can have everyone commit to a single archive if you prefer, too.
* signed revisions. arch can sign (with gpg) every change made to an archive, so other people can verify who actually made a change.
* archives can be made available to others via a variety of protocols, including http and ftp. yes, you can host a arch archive on cheap webspace somewhere, or in your ~/public_html/.
As far as I know, BK doesn't do the last two, but does the rest. On the other hand, BK does handle some less common patch-flows better than arch does.
Arch does need more tools around it, but the basics are there. There are 3 web-based viewer things for it,
See, people who've only used CVS and Subversion just don't understand why subversion will never be suitable for this.
Imagine if the kernel was in subversion, and you wanted to make a change. You'd check it out and change it, make a diff and send it to the list. uh, yay, it's just like working with tarballs. But, if it was in Arch or BK, you'd make your own *local* branch on your machine, make whatever changes you like in it, commit to it (offline if you like, since the archive is on YOUR machine), move files around, etc, etc. When you're done, you merge the changes Linus has made in his tree into yours (so he has less merging to do), and tell him where your archive is hosted (arch can serve your archives to other people via plain http/ftp/webdav, BK has it's own daemon, aiui).
Oh yes, and how do you merge linus's changes into your tree? "tla star-merge <name-of-linus-branch>". No fucking around finding what you've merged before, arch keeps track of that for you. BK does the same.
Merely my brief experience with Gentoo, when they first upgraded glibc (from 2.2 to 2.3 iirc) and broke half the packages.
This is a gentoo problem, not a Linux one; I've been through two glibc changes on Debian without breaking anything.
2.) it has exec-shield stack protection enabled by default but its less secure than your precious debian who got owned last month right? if they used exec-shiled that brk() exploit would have failed (yes i know debian will have it soon, thank ingo who works at redhat for that).
Uh, no. None of the Linux security patches would have protected the Debian systems from this attack. Not SELinux, not GRSecurity, not ExecShield. If it had been a Fedora system, it would have been 0wned just the same.
Debian has Perl 5.6 in unstable at the moment.
/ .
This has been wrong for months. packages.debian.org is still down, but look here http://http.us.debian.org/debian/pool/main/p/perl
UNCONSTITUTIONAL