a true AI that could pass the Turning Test would itself want a PDA to help it out
Heh. And the converse also! I once overheard a conversation where someone said "If my phone really was smart, it wouldn't want to be my phone in the first place."
Do you also like the tree conflicts you get when moving directories around in your project? Those are my favorite thing in SVN. In theory, they've made this better in the new version but I'll believe it when I see it myself. That's something about SVN that just really pisses me off.
Tree conflicts are inherent to any version control system, not just Subversion.
People complain about Subversion's tree conflict handling a lot. I believe this is because development work done so far was only about detection of tree conflicts, leaving many users helpless because tree conflicts can be complex and hard to understand and resolve.
The 1.8 release is taking some steps towards the eventual goal of helping users resolve any tree conflicts instead of merely detecting them. If you move a file or directory in Subversion 1.8, and need to update the working copy before committing the rename, and the update receives edits for the renamed file or directory, you'll now see a menu which allows you to apply the incoming changes to the renamed location:
Tree conflict on 'foo.txt' > local file moved away, incoming file edit upon update Select: (mc) apply update to move destination, (p) postpone, (q) quit resolution, (h) help:
This only works for 'svn update', however. It doesn't work for 'svn merge', yet. That's planned for a future release.
It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk.
This limitation has been lifted in 1.8. As long as you use no merge commands more complex than
svn merge ^/branch/to/merge/from
the merge works in either direction and should never flag spurious conflicts caused by changes being applied more than once.
There were ways to work around deleting a reintegrated branch in 1.7, by the way. But the new 1.8 merging works better. Just forget about --reintegrate, don't use any -r or -c options, and you can always merge in either direction without any need for deleting branches.
I'm a Subversion developer and would like to clarify this bit of the summary:
Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.
The "new metadata storage engine" probably refers to FSFS which has been the default repository backend since Subversion 1.2. FSFS has been improved since then, and 1.8 contains some new improvements (such as directory deltification) but does not add a new repository backend. The BDB-based backend is the one from Subversion 1.0 and is rarely used these days.
Subversion 1.8 doesn't contain support for "first-class renames". Renames are still modeled as copy+delete, with special annotations. The working copy is so far the only part of the system which is aware of moves. There are plans to make other subsystems aware of moves in future releases. Also, while tree-conflicts involving local moves can now be auto-resolved after 'svn update', 'svn merge' mostly behaves as it did in 1.7, expect there is no need to use the --reintegrate option and tree conflicts are now flagged if a directory was renamed or deleted on the merge source branch. Whereas Subversion 1.7 would unconditionally perform the deletion in the merge target.
I'm sad to hear that someone ripped off your work and resold it as their own. That's unjust, and it's one of the inherent risks of open source development.
There is a healthy variant of this where companies build a product based on an open source code base, something that adds value but is doing something that the community around the open source project isn't interested in doing. Many companies do this, including Facebook and Yahoo, who fund development of of e.g. Apache Hadoop, and Apple who are using BSD and Apache-licensed code in OS X. If you're doing this well, you feed back any changes the community might be interested in. And that doesn't mean just dropping some code on their lists and walking away. You need to interact nicely, react to community feedback, and eventually become part of the community and share some responsibility.
Whoever sold your work as their own took the irresponsible and damaging route with the above approach, looking for short-term profit only, with no interest in supporting the original project. To fight this, you can use a copyleft licence and enforce it if it is violated, and/or build a community that is strong and dedicated to supporting the original product (this is why new projects at the Apache Software Foundation go through an incubating phase that builds up a community around the project -- the project graduates once the community is deemed healthy). As an additional lever, you could also trademark your product's name to ensure that others who use your work cannot use the same name for their own product but must rebrand it.
You can also sell services that relate to the software. E.g. where I work we sell support and consulting for open source development tools (svn, git, eclipse, and the like). We also contribute to some of the projects we sell services for, so money people pay for our services partly funds further development of these open source tools. We make sure clients are aware of that, and they are usually quite happy about getting support from someone who is a developer on the project. This gives us a small competitive edge over others who sell consulting for these open source products but don't interact with the open source community.
The ultimate issue is that renames (or moves) are implemented as delete+addition operations. Maybe back in the day, that appeared to be ok, but now its obvious it's a large failing.
That's not the problem. Mercurial also does this, and nobody (at least on slashdot:-) is complaining about Mercurial's rename implementation.
If you look closely, Mercurial has problems with its rename implementation, as does *gasp* git.
See my BSc thesis for details: https://www.inf.fu-berlin.de/w/SE/ThesisTreeConflicts
The problem with Subversion's implementation is that people are much more likely to run into some of its very annoying shortcomings in practice. But there are only a handful of cases which Subversion needs to handle better to catch up (though making these cases happen is a lot of work, see
my other comment here: http://news.slashdot.org/comments.pl?sid=1934004&cid=34755596).
Take a look at the tables on pages 29 and 30 in the thesis pdf. Note that these were based on Subversion 1.5 behaviour. Subversion 1.6 already detects more of these cases than git and hg combined, but it doesn't even try to automatically resolve any of them, even trivial cases. This is why hg's and git's merging are working nicer in practice right now. In theory there is no tool that hasn't got severe problems if you put the bar up high enough. Would you possibly want sane conflict resolution when merging directories across branches (table on page 30)? Sorry, there is no open source tool that can do that, yet...
It is entirely possible that this will never happen in any reasonable time frame without re-engineering the whole system. If it can happen with relatively minor changes, it should have happened by now.
Speaking as a Subversion committer: Yes, you're right, it will still take a long time. It's very hard to make it work with a few small changes because the system contains quite a lot of layers of abstractions. We need to peel at each layer to make this work.
Each layer has a public API with some amount of compatibility guarantees. Which is both a blessing and a burden. It's a blessing for people who want to write tooling around Subversion, because they know that the tools they've written against Subversion at, say, version 1.0, will still work, without recompilation, with any subsequent 1.x release. This allowed a lot of third party tools of decent quality to be developed. No need for parsing command line output to interface with the version control tool (as was the case with CVS and AFAIK is still, today, with git). But it's a burden because it means we have to be careful not to break existing interfaces when making changes.
I wasn't around when the API compatibility guidelines were set up, and my life would be easier if they weren't there now. But the project is committed to keep them. Trying to fix things anyway is quite a challenge. It's very, very hard, and has to happen in lots of small steps, spread out over several release cycles. But it's a lot of fun, too.
We're currently rewriting the lowest layer on the client side, the working copy library. This will eventually allow us to do things like tracking local renames, so that tree conflicts involving a local rename will be solved more or less automatically. There will eventually also be improvements in other layers, e.g. client/server interface, and eventually the repository itself. Then we can start propagating rename information from the server to the client to close the loop and also handle non-local renames properly. When? Dunno. When it's done. It will take longer than many would like in any case.
If it is going to require major changes, somebody is essentially going to have to fork it and redo the core SCM storage from the ground up.
I don't see how forking would magically help with bringing about the desired changes any faster. You might just as well try to write a new and perfect centralized version control system from scratch. Or join the few people who are still actively committed to bringing Subversion forward and help us out. Subversion has already solved an awful lot of problems any centralized version control tool has to deal with. The glass is half-full when you look at it that way.
The problem is that the RT2500 chipset is proprietary, closed-source that's "maintained" by a Taiwanese manufacturer who doesn't care about his users at all and only wants to sell cheap hardware and as much of it as possible.
Well, actually, Ralink has for a long time been providing documentation to open source developers writing drivers for their devices, without requiring an NDA.
You could certainly put drivers in a higher ring than the kernel and allow them to only have limited access to memory, just as you do with a user-space application.
X.org has lots of userspace drivers that many of us use every day.
it totally breaks all that added security you were supposed to get through virtualization
Virtualization does not add any security to the overall system.
Adding more code to a system cannot make it more secure by definition.
You need less code running in the system to have less bugs in the system that malware authors can exploit.
Adding virtualization adds yet another attack vector for malware: attacking the hypervisor.
See http://en.wikipedia.org/wiki/Blue_Pill_(malware), for example.
There are good reasons for using virtualization, but improving overall system security isn't one of them.
I'd take that comment with a grain of salt.
I will be mentoring a student, too.
And yes, I expect to be bouncing patches back to students (we have two), and suggest improvements,
and maybe even provide a code example here and there to help them. It's part of the learning process they will go through. Just like any contributor.
But coding is only one side of open source development. There are many more.
Another goal is to try to integrate the student with the project, and let it be a fun and
rewarding experience. If students stay with the project even after the summer of code is
over, you've done the best possible job as a mentor. That is the hard part.
It's much harder than getting the code right.
Was Google created to promote and facilitate illegal file-sharing? No? Then Google is safe.
And what about Slashdot? Was it created to promote and facilitate illegal file-sharing? No?
Well maybe not unless you follow
this link and copy the content you are seeing to
your friend's computer.
Come on. This ruling breaks the internet.
I studied CS at FU-Berlin,
the program can be quite demanding, but it's very good. Some courses are taught in English,
and in those courses you can write the exams in either German or English. If you're
just going to spend a semester abroad, you may be able to get away with taking all
your courses in English.
You'll inevitably need to learn some German though, if only for social life (even though
many people are fluent in English), but the effort may well be worth it.
There is also a welcoming Linux geek society
at the faculty.
Oh, and Berlin is a very nice city. There's the typical tourist attractions, but also a large
and very active hacking community which naturally provides lots of entertainment for CS students (projects such as the CCC,
freifunk, C-base,
bootlab). Beware -- many students have been known to end
up stranded in these communities.
Check here for information about application procedures for students from abroad.
Did anybody spot that most of the article was dedicated to describing the game and its distribution hopes, as if it were a game review, while the confiscation itself got just a single sentence in the article? This is a fucking advert.
Yep, and it sure worked:
The server at www.waronterrortheboardgame.com is taking too long to respond.
English summary of TFA's source,
an interview with chief prosecutor of the German state
North Rhine-Westphalia for all ye non-German speakers here:
He is saying that they primarily want to focus their resources
on prosecuting copyright violations which have a commercial background.
They consider 3.000 illegally shared audio files and 200 illegally shared
movie files lower bounds for commercial background, respectively.
He is saying that they derived these numbers from the assumption
that, on average, an audio file was worth 1 euro, and a movie file
was worth 15 euro, resulting in commercial damages of 3.000 euro each.
He's saying that, inspite of this, illegally sharing copyrighted
material is still illegal.
Furthermore, he states that in his jurisdiction
(the biggest one of three total in North-Rhine Westphalia),
there were around 25.000 cases related to copyright
infringement filed in court within the first half of 2008.
He is saying that in his experience, most of these cases
get filed to get at the identity of people behind IP addresses
in order to sue them for damages.
He's saying that network operators charge the prosecutors (that's him)
17 euro per hour for matching up IP addresses to people. They can do
this according to German law.
He also states that all these cases
add considerable overhead to their day-to-day operations because
they are binding a lot of their resources.
While he's saying that copyright infringement is to be considered
a criminal act, he also says that it is a lesser criminal act
than others.
The interviewer compares filesharing to consuming Cannabis, which
the interviewer says is being treated similarly. The interviewer says
that both copyright infringement and consuming Cannabis were primarily
done by younger people.
The chief ackknowledges the interviewer's remark that both of these
are primarily done by younger people. He says that juvenile behaviour
should not be criminalised in each and every case, and that focusing their
entire resources on such cases was out of proportion.
I'd be surprised if research on sensor networks wasn't done across the entire planet.
Our CS department (located in the northern hemisphere) does more or less the same thing:
I'm really upset with my comcast internet. I wish it was much cheaper and even faster.
Dude, according to the comcast article at wikipedia, you won't cause much of a stir with this. The bar's been set a tad higher already. Meet Mrs. Shaw:
On October 15, 2007, a 75-year old Comcast customer named Mona Shaw entered her local Comcast offices with a hammer and destroyed some office equipment before being arrested and fined for damages. Mrs. Shaw was angry and frustrated due to a previous encounter with Comcast customer service in which she and her husband wanted to speak with the manager and were forced to wait outside the offices for two hours before being informed that the manager had already gone home.
The teams working on the new round of decentralized SCMs[*] have done deep rethinking of source control problems and challenges, and the results are generally brilliant. These problems aren't esoteric -- administration and day-to-day usage really is easier with the new stuff. After a while using git, Bazaar, etc., the crufty old SCM tools seem like doing image editing in a hex editor instead of a GUI app.
You're painting this far too black and white.
Distributed systems have their own set of limitations,
some of which centralized tools don't have. Some development processes cannot be implemented with distributed
tools, pretty much the same way as processes such as how the Linux kernel is developed cannot be implemented
by centralized tools.
For example:
Let's say I wanted to make sure that any change going into my project enters the main line, or "trunk",
first, and is then applied to release branches if necessary. This makes sure that I have one common place
to log all changes ever entering my code base. That's very simple requirement, right?
This approach is used by many projects, e.g. by all the BSDs, and by Subversion itself.
Let's say I picked Mercurial as my tool for the job.
So I have a changeset on my trunk, and I want to merge it into my 1.x and my 2.x release branches.
I will first need to pull the change from trunk into my branch, right?
hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [SOURCE]
-r --rev a specific revision up to which you would like to pull
Wait... why does it say "up to which"? I just want that one change!
Darn, turns out that in Mercurial, changesets depend on all their ancestors
in order to guarantee integrity of all changes I pull from another clone of my repo.
You cannot pull a change without having around its parent, since revisions are identified
by hashes in order to be globally unique across all clones. The hash of a revision
is derived partly from the hashes of its parent revisions (they are included in the manifest).
So I need all parent revisions of my changeset in my branch. Since I've forked off my branch
from trunk, and have not yet made changes to the branch itself (remember that all changes to the branch
should be coming in via trunk), Mercurial will see no conflicting heads and simply forward my
release branch to the latest head of trunk. So I can either pull every change I've made on trunk since
forking the release branch (not much point in that), or manually apply a patch to the release branch (i.e. side-step the tool).
Well, great. With Subversion 1.5, all you need to do to get a changeset, say rev 42, from trunk
to a release branch is
So in practice, people using Mercurial end up fixing problems on their release branches,
and merge the fixes to their main line later. And yes, it seems like you have to manually
apply a fix to all your release branches separately (at least I haven't yet found another way).
This extension maintains a special file mapping local changeset hashes to remote ones.
You have to bet your luck on not ever creating the same hash for two different revisions, though,
otherwise your project's history is borked (I have no idea how likely this is).
Certainly, maintaining a separate list of changeset ids is not something intended in the
original design, which focused on providing distributed branching and merging. The design
does a very good job at this no doubt. By making sure that all bran
I understood the sentence perfectly while reading the summary, but I guess I could only understand
it because I am familiar with the highlighted terms:
'..the structure and internal quality attributes of a working, non-trivial software artifact
will represent first and foremost the engineering requirements of its construction, with the influence of process
being marginal, if any.'
Both these terms have their origin, as far as I know, in software configuration management.
Which itself seems to be a commonly misunderstood term, even by many computer scientists and hackers. I've met a few
people who started thinking "managing configuration files" at first.
I don't think it's bad to use these kinds of terms in a paper (not that I knew a lot about scientific writing).
As long as their context and origin is made clear it should be fine.
As for these terms appearing in a slashdot summary: There are many, many
occasions where I don't understand summaries very well either, so I don't think it's too much of an issue.
In the end it all depends on which of the many fields of CS people reading the summary dabble in... uhm, we're all computer geeks here, right?:)
BTW, reading Code Quality atm, and liking it. Great book!
Slashdot Mirror
Heh. And the converse also! I once overheard a conversation where someone said "If my phone really was smart, it wouldn't want to be my phone in the first place."
This has already been answered here: http://marc.info/?l=openbsd-mi...
Tree conflicts are inherent to any version control system, not just Subversion.
People complain about Subversion's tree conflict handling a lot. I believe this is because development work done so far was only about detection of tree conflicts, leaving many users helpless because tree conflicts can be complex and hard to understand and resolve.
The 1.8 release is taking some steps towards the eventual goal of helping users resolve any tree conflicts instead of merely detecting them. If you move a file or directory in Subversion 1.8, and need to update the working copy before committing the rename, and the update receives edits for the renamed file or directory, you'll now see a menu which allows you to apply the incoming changes to the renamed location:
This only works for 'svn update', however. It doesn't work for 'svn merge', yet. That's planned for a future release.
This limitation has been lifted in 1.8. As long as you use no merge commands more complex than
the merge works in either direction and should never flag spurious conflicts caused by changes being applied more than once.
There were ways to work around deleting a reintegrated branch in 1.7, by the way. But the new 1.8 merging works better. Just forget about --reintegrate, don't use any -r or -c options, and you can always merge in either direction without any need for deleting branches.
I'm a Subversion developer and would like to clarify this bit of the summary:
The "new metadata storage engine" probably refers to FSFS which has been the default repository backend since Subversion 1.2. FSFS has been improved since then, and 1.8 contains some new improvements (such as directory deltification) but does not add a new repository backend. The BDB-based backend is the one from Subversion 1.0 and is rarely used these days.
Subversion 1.8 doesn't contain support for "first-class renames". Renames are still modeled as copy+delete, with special annotations. The working copy is so far the only part of the system which is aware of moves. There are plans to make other subsystems aware of moves in future releases. Also, while tree-conflicts involving local moves can now be auto-resolved after 'svn update', 'svn merge' mostly behaves as it did in 1.7, expect there is no need to use the --reintegrate option and tree conflicts are now flagged if a directory was renamed or deleted on the merge source branch. Whereas Subversion 1.7 would unconditionally perform the deletion in the merge target.
Here's another such window:
http://events.ccc.de/congress/2012/Fahrplan/events/5338.en.html
http://mirror.fem-net.de/CCC/29C3/mp4-h264-LQ-iProd/29c3-5338-en-enemies_of_the_state_h264-iprod.mp4
I'm sad to hear that someone ripped off your work and resold it as their own. That's unjust, and it's one of the inherent risks of open source development.
There is a healthy variant of this where companies build a product based on an open source code base, something that adds value but is doing something that the community around the open source project isn't interested in doing. Many companies do this, including Facebook and Yahoo, who fund development of of e.g. Apache Hadoop, and Apple who are using BSD and Apache-licensed code in OS X. If you're doing this well, you feed back any changes the community might be interested in. And that doesn't mean just dropping some code on their lists and walking away. You need to interact nicely, react to community feedback, and eventually become part of the community and share some responsibility.
Whoever sold your work as their own took the irresponsible and damaging route with the above approach, looking for short-term profit only, with no interest in supporting the original project. To fight this, you can use a copyleft licence and enforce it if it is violated, and/or build a community that is strong and dedicated to supporting the original product (this is why new projects at the Apache Software Foundation go through an incubating phase that builds up a community around the project -- the project graduates once the community is deemed healthy). As an additional lever, you could also trademark your product's name to ensure that others who use your work cannot use the same name for their own product but must rebrand it.
You can also sell services that relate to the software. E.g. where I work we sell support and consulting for open source development tools (svn, git, eclipse, and the like). We also contribute to some of the projects we sell services for, so money people pay for our services partly funds further development of these open source tools. We make sure clients are aware of that, and they are usually quite happy about getting support from someone who is a developer on the project. This gives us a small competitive edge over others who sell consulting for these open source products but don't interact with the open source community.
An excellent description of the role money can play in an open source project is given by Karl Fogel at http://www.producingoss.com/en/money.html
.
That's not the problem. Mercurial also does this, and nobody (at least on slashdot :-) is complaining about Mercurial's rename implementation.
If you look closely, Mercurial has problems with its rename implementation, as does *gasp* git.
See my BSc thesis for details: https://www.inf.fu-berlin.de/w/SE/ThesisTreeConflicts
The problem with Subversion's implementation is that people are much more likely to run into some of its very annoying shortcomings in practice. But there are only a handful of cases which Subversion needs to handle better to catch up (though making these cases happen is a lot of work, see my other comment here: http://news.slashdot.org/comments.pl?sid=1934004&cid=34755596).
Take a look at the tables on pages 29 and 30 in the thesis pdf. Note that these were based on Subversion 1.5 behaviour. Subversion 1.6 already detects more of these cases than git and hg combined, but it doesn't even try to automatically resolve any of them, even trivial cases. This is why hg's and git's merging are working nicer in practice right now. In theory there is no tool that hasn't got severe problems if you put the bar up high enough. Would you possibly want sane conflict resolution when merging directories across branches (table on page 30)? Sorry, there is no open source tool that can do that, yet...
Speaking as a Subversion committer: Yes, you're right, it will still take a long time. It's very hard to make it work with a few small changes because the system contains quite a lot of layers of abstractions. We need to peel at each layer to make this work.
Each layer has a public API with some amount of compatibility guarantees. Which is both a blessing and a burden. It's a blessing for people who want to write tooling around Subversion, because they know that the tools they've written against Subversion at, say, version 1.0, will still work, without recompilation, with any subsequent 1.x release. This allowed a lot of third party tools of decent quality to be developed. No need for parsing command line output to interface with the version control tool (as was the case with CVS and AFAIK is still, today, with git). But it's a burden because it means we have to be careful not to break existing interfaces when making changes.
I wasn't around when the API compatibility guidelines were set up, and my life would be easier if they weren't there now. But the project is committed to keep them. Trying to fix things anyway is quite a challenge. It's very, very hard, and has to happen in lots of small steps, spread out over several release cycles. But it's a lot of fun, too.
We're currently rewriting the lowest layer on the client side, the working copy library. This will eventually allow us to do things like tracking local renames, so that tree conflicts involving a local rename will be solved more or less automatically. There will eventually also be improvements in other layers, e.g. client/server interface, and eventually the repository itself. Then we can start propagating rename information from the server to the client to close the loop and also handle non-local renames properly. When? Dunno. When it's done. It will take longer than many would like in any case.
I don't see how forking would magically help with bringing about the desired changes any faster. You might just as well try to write a new and perfect centralized version control system from scratch. Or join the few people who are still actively committed to bringing Subversion forward and help us out. Subversion has already solved an awful lot of problems any centralized version control tool has to deal with. The glass is half-full when you look at it that way.
Well, actually, Ralink has for a long time been providing documentation to open source developers writing drivers for their devices, without requiring an NDA.
X.org has lots of userspace drivers that many of us use every day.
No no no, your assumption was correct!
Virtualization does not add any security to the overall system. Adding more code to a system cannot make it more secure by definition. You need less code running in the system to have less bugs in the system that malware authors can exploit. Adding virtualization adds yet another attack vector for malware: attacking the hypervisor. See http://en.wikipedia.org/wiki/Blue_Pill_(malware), for example. There are good reasons for using virtualization, but improving overall system security isn't one of them.
I'd take that comment with a grain of salt.
I will be mentoring a student, too.
And yes, I expect to be bouncing patches back to students (we have two), and suggest improvements, and maybe even provide a code example here and there to help them. It's part of the learning process they will go through. Just like any contributor.
But coding is only one side of open source development. There are many more. Another goal is to try to integrate the student with the project, and let it be a fun and rewarding experience. If students stay with the project even after the summer of code is over, you've done the best possible job as a mentor. That is the hard part. It's much harder than getting the code right.
And what about Slashdot? Was it created to promote and facilitate illegal file-sharing? No? Well maybe not unless you follow this link and copy the content you are seeing to your friend's computer.
Come on. This ruling breaks the internet.
I studied CS at FU-Berlin, the program can be quite demanding, but it's very good. Some courses are taught in English, and in those courses you can write the exams in either German or English. If you're just going to spend a semester abroad, you may be able to get away with taking all your courses in English. You'll inevitably need to learn some German though, if only for social life (even though many people are fluent in English), but the effort may well be worth it. There is also a welcoming Linux geek society at the faculty. Oh, and Berlin is a very nice city. There's the typical tourist attractions, but also a large and very active hacking community which naturally provides lots of entertainment for CS students (projects such as the CCC, freifunk, C-base, bootlab). Beware -- many students have been known to end up stranded in these communities. Check here for information about application procedures for students from abroad.
Yep, and it sure worked:
Yes, because you don't have to go through US customs on your way to the conference :)
I'd be surprised if research on sensor networks wasn't done across the entire planet. Our CS department (located in the northern hemisphere) does more or less the same thing:
http://cst.mi.fu-berlin.de/projects/ScatterWeb/index.html
A few pictures of the hardware are here:
http://cst.mi.fu-berlin.de/projects/ScatterWeb/hardware/index.html
It's fun to program these little guys, I made one of them blink LEDs and beep at people entering the room once, sooo cute :)
Dude, according to the comcast article at wikipedia, you won't cause much of a stir with this. The bar's been set a tad higher already. Meet Mrs. Shaw:
If you want to know more about the hammer file system, check http://bsdtalk.blogspot.com/2008/07/bsdtalk154-matthew-dillon.html
You're painting this far too black and white.
Distributed systems have their own set of limitations, some of which centralized tools don't have. Some development processes cannot be implemented with distributed tools, pretty much the same way as processes such as how the Linux kernel is developed cannot be implemented by centralized tools.
For example:
Let's say I wanted to make sure that any change going into my project enters the main line, or "trunk", first, and is then applied to release branches if necessary. This makes sure that I have one common place to log all changes ever entering my code base. That's very simple requirement, right? This approach is used by many projects, e.g. by all the BSDs, and by Subversion itself. Let's say I picked Mercurial as my tool for the job.
So I have a changeset on my trunk, and I want to merge it into my 1.x and my 2.x release branches. I will first need to pull the change from trunk into my branch, right?
Wait... why does it say "up to which"? I just want that one change!
Darn, turns out that in Mercurial, changesets depend on all their ancestors in order to guarantee integrity of all changes I pull from another clone of my repo. You cannot pull a change without having around its parent, since revisions are identified by hashes in order to be globally unique across all clones. The hash of a revision is derived partly from the hashes of its parent revisions (they are included in the manifest).
So I need all parent revisions of my changeset in my branch. Since I've forked off my branch from trunk, and have not yet made changes to the branch itself (remember that all changes to the branch should be coming in via trunk), Mercurial will see no conflicting heads and simply forward my release branch to the latest head of trunk. So I can either pull every change I've made on trunk since forking the release branch (not much point in that), or manually apply a patch to the release branch (i.e. side-step the tool).
Well, great. With Subversion 1.5, all you need to do to get a changeset, say rev 42, from trunk to a release branch is
So in practice, people using Mercurial end up fixing problems on their release branches, and merge the fixes to their main line later. And yes, it seems like you have to manually apply a fix to all your release branches separately (at least I haven't yet found another way).
In all fairness, there is in fact an extension that allows Mercurial to "transplant" a changeset from one branch to another without requiring you to also merge all the parents of the changeset: http://www.selenic.com/mercurial/wiki/index.cgi/TransplantExtension
This extension maintains a special file mapping local changeset hashes to remote ones. You have to bet your luck on not ever creating the same hash for two different revisions, though, otherwise your project's history is borked (I have no idea how likely this is).
Certainly, maintaining a separate list of changeset ids is not something intended in the original design, which focused on providing distributed branching and merging. The design does a very good job at this no doubt. By making sure that all bran
I understood the sentence perfectly while reading the summary, but I guess I could only understand it because I am familiar with the highlighted terms:
Both these terms have their origin, as far as I know, in software configuration management. Which itself seems to be a commonly misunderstood term, even by many computer scientists and hackers. I've met a few people who started thinking "managing configuration files" at first.
I don't think it's bad to use these kinds of terms in a paper (not that I knew a lot about scientific writing). As long as their context and origin is made clear it should be fine. As for these terms appearing in a slashdot summary: There are many, many occasions where I don't understand summaries very well either, so I don't think it's too much of an issue. In the end it all depends on which of the many fields of CS people reading the summary dabble in... uhm, we're all computer geeks here, right? :)
BTW, reading Code Quality atm, and liking it. Great book!