Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apache Subversion To WANdisco, Inc: Get Real

Soulskill posted more than 3 years ago | from the you're-not-the-boss-of-me dept.

Open Source 85

kfogel writes "The Apache Subversion project has just had to remind one of its corporate contributors about the rules of the road. WANdisco, Inc was putting out some very odd press releases and blog posts, implying (among other things) that their company was in some sort of steering position in the open source project. Oops — that's not the Apache Way. The Apache Software Foundation has reminded them of how things work. Meanwhile, one of the founding developers of Subversion, Ben Collins-Sussman, has posted a considerably more caustic take on WANdisco's behavior."

cancel ×

85 comments

Sorry! There are no comments related to the filter you selected.

red? (0)

Anonymous Coward | more than 3 years ago | (#34751678)

why was this link red compared to the usual green?

Re:red? (1)

93 Escort Wagon (326346) | more than 3 years ago | (#34751724)

why was this link red compared to the usual green?

Because this story was sponsored by (RED) [joinred.com] .

You know, just like those red iPods, boxes of breakfast cereal, and other random crap where the attempted tie-in makes no sense.

Re:red? (0)

Anonymous Coward | more than 3 years ago | (#34751750)

Maybe you're color blind?

Re:red? (2, Informative)

Anonymous Coward | more than 3 years ago | (#34752120)

Since nobody has given you a straight answer:

Stories get red backgrounds behind the title, rather than green, when it's in the mode where it gets shown to subscribers (the people who actually pay /. money) earlier than the rest of us.

For a short period right after it becomes generally visible, they also appear to be red - I assume there's a caching problem or something along those lines.

Just ignore it; it's not special.

Re:red? (1)

PatPending (953482) | more than 3 years ago | (#34758612)

Stories get red backgrounds behind the title,

As opposed to "backgrounds in front of the title." :P

Signed,

Department for Anti-Redundancy Department

Re:red? (1)

wideBlueSkies (618979) | more than 3 years ago | (#34794160)

One thing to note. The comment feature is unavalable in subscriber preview mode. So just becasue you pay to support the site, it doesn't mean that you get to crowd in first posts ahead of the community. Which I think is a fair thing, speaking as a subscriber.

Re:red? (0)

Anonymous Coward | more than 3 years ago | (#34753198)

Because WANdisco is subverting the community. I can't believe no-one else said it.

Open! (4, Insightful)

nhaines (622289) | more than 3 years ago | (#34751682)

The beautiful thing, though, is that because development discussion is held in open, publicly archived mailing lists and all development is done in logged, publicly accessible source code repositories, the interested observer can investigate and come to the real conclusion on his own to see whether either party's explanation makes sense.

Re:Open! (4, Insightful)

Hognoxious (631665) | more than 3 years ago | (#34752038)

the interested observer can investigate and come to the real conclusion on his own

Meanwhile, the other 99.99% will listen to whoever shouts loudest - just like they do with everything else.

Re:Open! (1)

Knightman (142928) | more than 3 years ago | (#34752062)

Re:Open! (0)

Anonymous Coward | more than 3 years ago | (#34752130)

It's only been around fore mere two months and already reached "obligatory" status? Man, things move quickly on the interwebs, but this is ridiculous.

Slashdot (1)

Anonymous Coward | more than 3 years ago | (#34752684)

99.99% will listen to whoever shouts loudest

This is precisely the problem with slashdot nowadays. Observe that on any given story, the first posts to get modded up are the "what do I need this for", "this sucks", "he's a prick" and so forth -- even the ones that don't provide any rationale whatsoever.

Conclusion: Slashdot is now comprised of greater than 50% teenagers.

Re:Slashdot (2)

silanea (1241518) | more than 3 years ago | (#34752836)

I remember reading about an analysis of Facebook comments and "like's" a while ago which concluded that negative posts receive the most attention. Apparently it is easier to respond to a negative attitude - either by arguing against it or expressing solidarity - than a positive one.

The same effect is visible in politics: It is the angry voters who rush to the polling stations, the content stay at home, even though the outcome of the election is equally important to both. There surely is a psychological explanation for this behaviour.

Re:Slashdot (1)

twidarkling (1537077) | more than 3 years ago | (#34753610)

The same effect is visible in more portions of life than that. Customer complaints are always more numerous than customer compliments, because if something pisses you off, you want it changed, but if something went fine, well, yay, I don't need to do anything, do I? That's why a lot of retail places offer incentives for customer service surveys, so that people who had good experiences have more of a reason to mention it. People don't seem to realize that if you only get feedback from one side, then you institute changes based on just that one side. If you like something the way it is, you need to mention it so that there is a reason to not change something.

Re:Slashdot (0)

Anonymous Coward | more than 3 years ago | (#34806434)

Slashdot is now comprised of greater than 50% teenagers.

Yup, and they're all on my lawn.

You'll be old and cynical one day, sonny.

Re:Open! (0)

Anonymous Coward | more than 3 years ago | (#34753150)

Meanwhile, the other 99.99% will listen to whoever shouts loudest - just like they do with everything else.

THEN LISTEN TO ME!!!!!!!1!!!!!!!1!!

Re:Open! (0)

Anonymous Coward | more than 3 years ago | (#34759044)

NO!

Re:Open! (1)

SpaghettiPattern (609814) | more than 3 years ago | (#34752400)

The beautiful thing, though, is that because development discussion is held in open, publicly archived mailing lists and all development is done in logged, publicly accessible source code repositories, the interested observer can investigate and come to the real conclusion on his own to see whether either party's explanation makes sense.

Sure, but confirming or rejecting allegations consumes resources. The grapevine "supports" many decisions. Rumours will most likely delay an opponent and rob him of resources.

Spreading unfounded rumours towards charity organisations is particularly evil as it damages their scarce resources. In many aspects Apache and many other open source projects can be considered charity organisations.

Re:Open! (1)

Khyber (864651) | more than 3 years ago | (#34758876)

The only conclusion I came to is that both parties are acting like little children having a tantrum.

And that pretty much steers my business away from wanting to use anything developed by them.

Smell test (4, Funny)

antifoidulus (807088) | more than 3 years ago | (#34751710)

If you take any organization called "WANdisco" seriously, you have bigger issues than where exactly your open source software came from :P

Re:Smell test (2)

PatPending (953482) | more than 3 years ago | (#34751738)

If you take any organization called "WANdisco" seriously, you have bigger issues than where exactly your open source software came from :P

Yeah, they really should have choosen a more professional name, such as WANdiscotheque.

Re:Smell test (0)

Anonymous Coward | more than 3 years ago | (#34751752)

WANmicrosoftway?

Re:Smell test (2)

PatPending (953482) | more than 3 years ago | (#34751784)

This just in: due to negative publicity surrounding his comments, WANdisco CEO David Richards has announced plans to rename the company WANkers.

Re:Smell test (2, Informative)

MadTinfoilHatter (940931) | more than 3 years ago | (#34751982)

This just in: due to negative publicity surrounding his comments, WANdisco CEO David Richards has announced plans to rename the company WANkers.

I recently had to assist implementing this software, and trust me, your suggestion would be a much more appropriate name. WANdisco is a horribly expensive solution to a problem that can be solved in much better and cheaper ways (the most obvious one being using something better than SVN in the first place). WANdisco essentially tries to do is turn the turd that is SVN into the turd that is ClearCase. Bleh!

Re:Smell test (2)

Aldenissin (976329) | more than 3 years ago | (#34753248)

Well then, we should be upset that they took the idea of wacky sounding names and made them look bad. I mean just when they were starting to get credibility, like GNU, Linux, KDE, GIMP, someone has to spoil the goldmine in names that WANdisco should have been! I mean really, WAN (haha get it, it's like a LAN, but bigger) and then disco(par-tae!)! I'm on the Internet, bopping along! /only trying to be half funny.

Re:Smell test (2)

Lumpy (12016) | more than 3 years ago | (#34752744)

And their flagship product....... SPROKETS!

Now is the time on Sprokets when we dance!

Re:Smell test (1)

snspdaarf (1314399) | more than 3 years ago | (#34753350)

And their flagship product....... SPROKETS!

Now is the time on Sprokets when we dance!

You can not touch my monkey.

Re:Smell test (1)

outsider007 (115534) | more than 3 years ago | (#34751804)

After this bad press I would suggest a name change to something that suggests a large degree of added functionality. Off the top of my head, maybe "GIANTtools"

Re:Smell test (4, Funny)

PatPending (953482) | more than 3 years ago | (#34751850)

Why don't you quit your Jive Talkin'?

WANdisco is simply focusing on Stayin' Alive in these difficult times.

So instead of making snide remarks, You Should Be Dancing in their Boogie Shoes!

And--did you ever think of this?--maybe their CEO Dave Richards has Night Fever from working in a Disco Inferno!

So if you're More Than a Woman, I ask: How Deep is Your Love for open source?

Now, my friend, is the time to step down from your Manhattan Skyline and spend a Night on Disco Mountain before you have a Calypso Breakdown!

(And maybe savor A Fifth of Beethoven while you're at it.)

And I do apologize for my ranting--I blame a relapse from Saturday Night Fever [wikipedia.org]

Re:Smell test (0)

Anonymous Coward | more than 3 years ago | (#34753114)

Why don't you quit your Jive Talkin'?

WANdisco is simply focusing on Stayin' Alive in these difficult times.

So instead of making snide remarks, You Should Be Dancing in their Boogie Shoes!

And--did you ever think of this?--maybe their CEO Dave Richards has Night Fever from working in a Disco Inferno!

So if you're More Than a Woman, I ask: How Deep is Your Love for open source?

Now, my friend, is the time to step down from your Manhattan Skyline and spend a Night on Disco Mountain before you have a Calypso Breakdown!

(And maybe savor A Fifth of Beethoven while you're at it.)

And I do apologize for my ranting--I blame a relapse from Saturday Night Fever [wikipedia.org]

To be Frank , when you Sheik Yerbouti I think you're just being a Disco Boy.

---

Re:Smell test (1)

Bassman59 (519820) | more than 3 years ago | (#34755392)

To be Frank , when you Sheik Yerbouti I think you're just being a Disco Boy.

---

Broken hearts are for assholes.

Re:Smell test (1)

wolowsj (1951140) | more than 3 years ago | (#34754524)

So funny.....I want to put on my disco shoes. Disco duck. Need one of those disco balls and the Travolta spinning jacket moves.

Re:Smell test (2)

jbatista (1205630) | more than 3 years ago | (#34752032)

I notice the post was labelled as "Funny", but really -- I can't imagine how much fun you have with company names such as "Google" or (even worse) "MICRO SOFT" (I suppose you'd choose to do business instead with a company called "MAJOR HARD").

Re:Smell test (1)

petteyg359 (1847514) | more than 3 years ago | (#34765378)

For that, you'd first have to find a company called MINORSOFT.

Re:Smell test (0)

Anonymous Coward | more than 3 years ago | (#34752690)

Yep, they smell,
and for a "professional" company they're up sh#ts creek...
here comes the spam (sung like the pixies "here comes your man")
what a bunch of dipwits, this CEO want's to ruin his company or what?

Re:Smell test (1)

0100010001010011 (652467) | more than 3 years ago | (#34755572)

But I should trust GIMP, Brain Fuck Scheduler, Gnome, Pidgin, Konqueror, etc?

The Apache Way (0)

Anonymous Coward | more than 3 years ago | (#34751778)

I assume a teepee and peace pipe are involved? Possibly some dancing?

Re:The Apache Way (1)

PatPending (953482) | more than 3 years ago | (#34751866)

The Apache Way (TM) is to hack 'em to bits.

Re:The Apache Way (0)

Anonymous Coward | more than 3 years ago | (#34752048)

...and then patch 'em together.

Loose cannon PR Agency stirs the pot (2)

joeflies (529536) | more than 3 years ago | (#34751822)

in order to get noticed. News at 11:00

Re:Loose cannon PR Agency stirs the pot (1)

duncan3dc (1228744) | more than 3 years ago | (#34753520)

Exactly, anybody heard of WANdisco before today?

Re:Loose cannon PR Agency stirs the pot (1)

KingRobot (703860) | more than 3 years ago | (#34755110)

Mod parent up

Bravo! (1)

SmoothTom (455688) | more than 3 years ago | (#34751832)

Well said, Ben!

--
Tomas

Subversion development _is_ slow (2)

prionic6 (858109) | more than 3 years ago | (#34751856)

While I have much respect for the Apache Foundation and do not know this WANdisco guys, anyone has to admit that subversion is lagging behind in core functionality. I don't mean distributed repositories, but the one feature pack that the other systems seemingly have right: branching and merging with real rename tracking. We try to avoid branches in our projects right now because it is so unwieldy. Merge tracking changed a few things but is not really sufficient if you refactor your package structure. This is a really important feature that is on the roadmap since, I don't know, five years? On the other hand, git and mercurial just don't have the tooling (GUI) that subversion has with TortoiseSVN, SmartSVN, the Eclipse SVN Handler... There might be equivalents, but they are not as good.

Of course, it easy to criticise an Open Source project when you are not contributing anything. But I would very much appreciate any effort that goes into speeding up the implementation of this stuff.

Re:Subversion development _is_ slow (2)

PatPending (953482) | more than 3 years ago | (#34751884)

I respectfully suggest you read the second link in The Fine Summary. All Will Be Revealed [red-bean.com] (TM).

Re:Subversion development _is_ slow (3, Interesting)

prionic6 (858109) | more than 3 years ago | (#34751906)

Yeah, I read that. And I get it. Subversion is a rock of a software. Yet still, I remember reading about rename tracking _years_ ago identified as a critical feature by the subversion developers themselves! And now it is on the roadmap for Q1 2012! At that pace, I don't know if maybe moving to another SCM may be the better option.

Re:Subversion development _is_ slow (4, Insightful)

butlerm (3112) | more than 3 years ago | (#34751896)

I don't mean distributed repositories, but the one feature pack that the other systems seemingly have right: branching and merging with real rename tracking

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. 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. A number of minor patches won't do. A version of the Innovator's Dilemma, more or less.

Re:Subversion development _is_ slow (1)

prionic6 (858109) | more than 3 years ago | (#34751926)

If it can happen with relatively minor changes, it should have happened by now. 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'm afraid you are right...

Re:Subversion development _is_ slow (-1, Offtopic)

purwantoaries (1970228) | more than 3 years ago | (#34752236)

I'm afraid you are right... http://thifaonline.co.cc/ [thifaonline.co.cc]

Re:Subversion development _is_ slow (3, Funny)

yahwotqa (817672) | more than 3 years ago | (#34752330)

Nah, they're just going to develop it in a separate branch, and merge it to trunk when it's done.

Re:Subversion development _is_ slow (1)

drinkypoo (153816) | more than 3 years ago | (#34753026)

A number of fairly simple tools can do this. It could involve changes to data formats, or storage of additional metadata, but there is no reason to believe that this should be difficult. Unison does it, and it's not a particularly competent project (it can't even synchronize between different versions. I mean, seriously. Have we never heard of capabilities?) If you don't want to build Unison yourself then you basically can't use it across different distributions. No distribution seems to use the latest release version so you end up having to build it everywhere to use it. And yet, they can do this.

Re:Subversion development _is_ slow (2)

stsp (979375) | more than 3 years ago | (#34755596)

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.

Re:Subversion development _is_ slow (1)

burymore (879896) | more than 3 years ago | (#34756008)

What would "help" is agreeing to break compatibility, which would definitely require a fork (or a "version 2.0", which is what the community keeps, in moments of darkest despair, suggesting). But an incompatible Subversion is hardly a Subversion at all (regardless of its name, number, or origin).

Re:Subversion development _is_ slow (1)

steelfood (895457) | more than 3 years ago | (#34760134)

The one thing forking will help overcome: backwards compatibility issues.

Seems Subversion is being bitten by the same thing that bit Microsoft for new versions of Windows and Office. I say do the massive changes necessary in one go and offer a compatibility layer afterwards. After all, nobody's going to be migrating their clients to 2.x if their server is still at 1.x.

Re:Subversion development _is_ slow (1)

SanityInAnarchy (655584) | more than 3 years ago | (#34751932)

What does Tortoise have that I'd miss? Gitk and git-gui are getting pretty good, especially at exposing what's actually going on in Git, and they're portable.

Re:Subversion development _is_ slow (2)

prionic6 (858109) | more than 3 years ago | (#34751956)

Tortoise is usable by about anyone in our company (at least the lowly windows using creatures). What I have heard and seen about gitk and git-gui, they are a bit "complicated" ;)

Re:Subversion development _is_ slow (1)

FictionPimp (712802) | more than 3 years ago | (#34753070)

And as I'm sure you know, there is a version of Tortoise for git and mercurial.

Re:Subversion development _is_ slow (1)

SanityInAnarchy (655584) | more than 3 years ago | (#34755566)

gitk, yes, maybe. Git-gui, really? From what I've seen, it manages to be both very easy to use (very little training needed, even for "lowly windows using creatures"), and a very faithful representation of what's actually going on in Git.

And I'm not sure gitk is meant to be a standalone GUI, but it works well as the "visualize" option in git-gui, just to show a tree of recent changes -- and I don't know of a subversion tool that can visualize merges like that.

Re:Subversion development _is_ slow (1)

prionic6 (858109) | more than 3 years ago | (#34757946)

I will look into git-gui and other stuff again...

Re:Subversion development _is_ slow (1)

Desler (1608317) | more than 3 years ago | (#34758794)

Tortoise is usable by about anyone in our company

So then use TortoiseGit [google.com] .

Re:Subversion development _is_ slow (0)

purwantoaries (1970228) | more than 3 years ago | (#34752246)

should immediately look for solutions to this problem (http://purwantoaries.co.cc)

Re:Subversion development _is_ slow (5, Informative)

LizardKing (5245) | more than 3 years ago | (#34752640)

At work we switched from Subversion to Mercurial last year, after repeated difficulties merging branches back into the trunk with SVN. The "killer feature" of SVN over CVS was supposed to be the ability to move files and directories around without doing it by hand in the repository itself. However, the moment you start doing this in a branched repository - or worse still, delete files and directories - you're into a world of hurt. The guy who wrote the existing branch/merge support has acknowledged it's inadequate[1], while the remaining SVN developers have been promising to fix it in the next version, for about the last four or five major versions. Since switching to Mercurial, we have had a reasonably large branch that was reintegrated into trunk with none of the problems we had with SVN. We've found the tools at least as good as those available for SVN, with various team members using the Mercurial command line client, NetBeans plugin and TortoiseHg.

Re:Subversion development _is_ slow (1)

LizardKing (5245) | more than 3 years ago | (#34752650)

[1] http://hgbook.red-bean.com/read/how-did-we-get-here.html [red-bean.com] (look for the comment by Ben Collins-Sussman under the comparison of Mercurial and Subversion, where he acknowledges that SVN branching and merging is "complicated and buggy").

Re:Subversion development _is_ slow (0)

Anonymous Coward | more than 3 years ago | (#34753442)

Nah, it's easier to just stop renaming files. Voila, problem solved!

Re:Subversion development _is_ slow (3, Insightful)

ka9dgx (72702) | more than 3 years ago | (#34752712)

... On the other hand, git and mercurial just don't have the tooling (GUI) that subversion has with TortoiseSVN, SmartSVN, the Eclipse SVN Handler... There might be equivalents, but they are not as good.

I've used TortoiseHg [bitbucket.org] for a while now, and it seems to be complete. Is it just that I'm a Mercurial Noob?

Re: TortoisHg incomplete? (1)

Omnifarious (11933) | more than 3 years ago | (#34755408)

To me it seems better than TortoiseSVN. I suspect this is because the main developer of both switched what he personally uses and only maintains TortoiseSVN so as not to abandon a userbase that's come to depend on it.

Re:Subversion development _is_ slow (2)

gbjbaanb (229885) | more than 3 years ago | (#34752898)

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 the reason you have problems with merging - merging is fine for changes to existing files, its merging new files where you get the problem. (look up 'tree conflicts' in svn for more info).

The rest of the system works well (though there's still a lot of svn haters for the usual reasons - they have something 'new' or 'cool', they just hate it because its mature and established, they hate it because they last tried it when it was version 1.2 and still think its has those limited features), and there is excellent tooling.

Git and mercurial lose some features that enterprises like, spare checkouts for example is a killer feature for enterprises that don't work well with DVCSs simply because of their original design.

BTW, I like the svn branching system, I've used a lot of scms in my time and svn is the only one that really shows you all the branches easily laid out for you to view - no stupid layers of branch views over the core code. You do have to manage it a little then, and there are features in svn like being able to branch at any point that I think might be worthless - always branch at the root and have done with any sub-directory complexity.

At the moment, the current push for implementation is the next-gen working copy which should be easier on Windows virus checkers and faster. I would hope the tree-conflict merge issue be tackled next.

Re:Subversion development _is_ slow (1)

PeterBrett (780946) | more than 3 years ago | (#34753116)

Git and mercurial lose some features that enterprises like, spare checkouts for example is a killer feature for enterprises that don't work well with DVCSs simply because of their original design.

What's a "spare checkout", exactly?

Re:Subversion development _is_ slow (3, Informative)

gbjbaanb (229885) | more than 3 years ago | (#34753314)

oops - typo. "Sparse checkout" [collab.net] . You can checkout a partial directory structure, update and commit as required.

So if you have a 12Gb source tree stored in your repo, you don't need to get it all out - only the parts you want to work on. Typically you checkout the root item only, then update the required directories to fetch them into your local drive as you need them.

Re:Subversion development _is_ slow (1)

stsp (979375) | more than 3 years ago | (#34755936)

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 [fu-berlin.de]

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 [slashdot.org] ).

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...

Re:Subversion development _is_ slow (1)

steelfood (895457) | more than 3 years ago | (#34760292)

The actual issue is the way branching works (or more accurately, doesn't work). The idea that a branch is no more than another directory is far too simplistic for any merge tracking.

The other issue is that files and directories are treated completely differently. Treating directories and files the same would go a long way to making branching more dynamic.

Fix these two core design issues, and branching and merging will be a piece of cake.

Re:Subversion development _is_ slow (1)

gbjbaanb (229885) | more than 3 years ago | (#34764074)

why is branching broken? Too simplistic? really.

The biggest issue with merging is the "tree conflict" where a directory list is modified. You don't need to treat a directory the same as file as its just a list of files - and you can determine that from the change in the revision (as files in that directory that are modified, added or deleted are recorded, which is exactly what you'd get if you stored directories the same as files).

However, because you cannot tell if a file has been moved, you have to delete it and then add the 'new' file, and this can cause problems, especially if the new files are further modified. If you're the only one working on this directory then there's no problem, but if you rename a file that your colleague has modified... the merge will find that it is trying to update changes into a file that appears to have been deleted, losing those changes. Hence the notification that human intervention is required. This notification isn't so easy to interpret though so perhaps the way merge errors are handled could be improved.

Other systems do track renames so this relatively common issue isn't seen, however, if you work in Windows and rename the file (and modify it) in explorer and then try to commit, even git or mercurial will have difficulty determining that its the same file and not a real delete and add.

WANdisco... (0)

Anonymous Coward | more than 3 years ago | (#34751868)

...should fork off.

drama queens (1)

nielzz (822766) | more than 3 years ago | (#34751872)

So this is what drama looks like in the open source world?

Re:drama queens (1)

Caerdwyn (829058) | more than 3 years ago | (#34759656)

So this is what drama looks like in the open source world?

One of several flavors. This is the "commercial company tries to elbow its way into a position of de facto control" flavor.

Others include:

  • Alpha-nerd pissfight
  • The "companies are now depending on this to not change" orthodoxy vs. "innovate, who cares who we hurt" heretics
  • Minutae-of-licensing sectarianism
  • The one hardworking contributor who knows what's going on retires without leaving an heir-apparent, triggering succession-wars
  • Oops. We stepped on an enforcable patent, and the patent-holder is serious.
  • "This sucks, service my complaint NOW!" entitlement-wanking
  • Project originator kills his wife and goes to jail

Any others to add? Let's hear 'em!

WANdisco's side (3, Informative)

FrootLoops (1817694) | more than 3 years ago | (#34751948)

Here's WANdisco's press release [wandisco.com] , their CEO's first blog post [wandisco.com] , and his second blog post [wandisco.com] responding to community response.

Re:WANdisco's side (1)

Anonymous Coward | more than 3 years ago | (#34753002)

It's pretty clear that this CEO is just another manager with that special kind of social blindness that never lets him believe he could make a mistake. Is it any different than what most of us see at work every day? Salespeople pushing their products with no regard to the impact they have on the world, just selling selling selling. With every breath they take or word they write or blog post they publish, selling selling selling.

Re:WANdisco's side (4, Insightful)

ralphart (70342) | more than 3 years ago | (#34753194)

I love his summation in the second blog post:

...Could these things have been said with a little less venom? Yes, probably. But the bottom line is that WE CARE because we have a deep vested interest in this Subversion stuff.

Translation: I'm a dickhead but that's okay because I'm awesome!

....Getting out of marketing and into IT was the best career move I ever made.

Re:WANdisco's side (1)

http (589131) | more than 3 years ago | (#34757082)

Or, translation: We're not interested in playing pretty, because we're dealing with dickheads hell-bent on breaking something essential.

Ben Collins-Sussman blog post (4, Informative)

FrootLoops (1817694) | more than 3 years ago | (#34752018)

[Note: The summary's second link seems to be getting slashdotted, so I'm copying its contents to a comment here. The words are not my own.]

This entry was posted by Ben Collins-Sussman [red-bean.com] on Monday, 3 January, 2011

Author’s Note: These opinions are my own. I'm one of the original folks that started the Subversion project, but no longer work on it. These thoughts do not reflect the official position of either the Subversion project or the Apache Software Foundation, which are located here [apache.org] on the ASF blog.

Subversion has reached the realm of Mature software — it’s yesterday’s technology, not cool or hip to work on anymore. It moves slowly. It is developed almost entirely by engineers working for corporations that need it or sell support for it. Alpha-geeks consider software like this “dead”, but the fact is that something like half of all corporate programmers use Subversion as their SCM (depending on which surveys you read.) This is a huge userbase; it may not be sexy, but it’s entrenched and here for the long haul.

Subversion isn’t unique in this position. It sits alongside other mature software such as Apache HTTPD or the GCC toolchain, which are famous projects that are similarly developed by corporate interests. There’s a tricky line to walk: none of these corporations “own” these projects. They understand that they’re acting as part of a consortium. Each interest sends representatives to the open source project, contributes code, and allows their engineers to participate in the full consensus-based evolution of the software. IBM, Apple, Google, and numerous other companies have figured out how to do this correctly:

  • 1. Let your engineers know what’s important to work on.
  • 2. Let them participate individually in the community process as usual.
  • 3. Profit. 98% of the time the corporations eventually get the features they want.

Today, however, we have a great counterexample of how not to participate in an open source project. Subversion was initially funded and developed by CollabNet; today at least two other companies — Elego and WANdisco — are employing numerous engineers to improve Subversion, and are just as vested in selling support and derivative products. CollabNet and Elego continue to function normally in the community, but WANdisco recently seems to have lost its marbles. Last week, they put out a press release [wandisco.com] and a CEO blogpost [wandisco.com] making some crazy statements.

It’s clear that the WANdisco CEO — David Richards — is frustrated at the slow pace at which Subversion is improving. But the two posts are simply making outrageous claims, either directly or via insinuation. David seems to believe that a cabal is preventing Subversion from advancing, and that “debate” is the evil instrument being used to block progress. He believes users are crying for the product to be improved, that the Subversion developers are ignoring them, and his company is now going to ride in on a white horse to save the project. By commanding engineers to Just Fix things, he’ll “protect the future”of Subversion, “overhauling” Subversion into a “radical new” product.

Is this guy for real? It sounds like someone read my friend Karl's book [producingoss.com] and created a farce of “everything you’re not supposed to do” when participating in corporate open source.

Even weirder, he’s accusing developers of trying game statistics by creating lots of trivial commits. This is staggering proof that he has no knowledge of the svn developer community or its culture. If he did, he would know that nobody counts stats at all or even cares about them. David appears so desperate to prove that his company is the “leader” that he accuses a community of behaviors that he’s doing himself. (”We have the most active developers of any other company on staff” — who’s counting stats here? The svn developers, or David?)

OK, fine. So Dave Richards is a salesperson, and perhaps what he wrote is generic PR sales junk in order to get his customers excited. Unfortunately, in attempting to woo customers, he’s had the side-effect of making his company appear both clueless and antagonistic to the project:

  • Clueless: It’s obvious he has no technical knowledge of Subversion’s design, has no idea why certain features have or haven’t been written yet, and hasn’t actually brought any new technical proposals or insights to the table. All he’s done is repeat descriptions of features that everybody wants. And he actually seems to believe that all one needs to do is throw more developers at the problems. Suuuuuure.
  • Antagonistic: He’s insulted two-thirds of the active developers (and embarrassed his own employees) by declaring them to be incompetant stewards. There’s no simpler way to garner hate and come off like an ass than to say “everyone move aside and let me fix this” — it’s the opposite of consensus-driven development. It’s a juvenile, conceited behavior that completely disrespects the people and the process.

The Subversion developer community (and ASF) are known for their cool, calm-headed responses to provocations like this, which they've just posted [apache.org] . They know not to feed trolls. But speaking as a private developer, I just had to point out WANdisco’s insanity and hold it up as a textbook example of how to Fail in the open source community process.

Re:Ben Collins-Sussman blog post (1)

drinkypoo (153816) | more than 3 years ago | (#34753050)

David seems to believe that a cabal is preventing Subversion from advancing, and that “debate” is the evil instrument being used to block progress. He believes users are crying for the product to be improved, that the Subversion developers are ignoring them, and his company is now going to ride in on a white horse to save the project.

Users are crying for the product to be improved. Decisions on future development in any OSS project usually are made by a "cabal", but it's typically nominally a meritocracy, with the people committing the code having the loudest voice. Finally, making some bold decisions and stepping out and changing the code could make drastic improvements, if you paid a group of people to make needed changes.

Note that I don't argue that this guy will do any of this... But only that it's possible.

Re:Ben Collins-Sussman blog post (5, Insightful)

horza (87255) | more than 3 years ago | (#34753336)

Ridiculously over the top. The ASF response was fair enough, in a United Nations kind of way, but trying to tear David Richards apart on a probably over the top PR piece is just as counter-productive.

The guy has stuck his head over the parapet and claims he will implement the features users most want. The rest of the community is scoffing at him saying it can't be done in the time he is projecting. Why not sit back and let him go ahead? Either he will fail in which case the PR piece will come back to haunt him, or he is going to give a massive boost to the Subversion project. Either way it's a win win for those like Ben Collins-Sussman disbelieving of his claims but use Subversion.

Why get dragged into petty politics, rather than saying "Let's see you put your money where your mouth is, I look forward to seeing monthly progress reports on the dev mailing list"? Get the guy to commit cash for code, rather than try and pick a playground fight.

Phillip.

Re:Ben Collins-Sussman blog post (3, Interesting)

makomk (752139) | more than 3 years ago | (#34755688)

The guy has stuck his head over the parapet and claims he will implement the features users most want. The rest of the community is scoffing at him saying it can't be done in the time he is projecting. Why not sit back and let him go ahead?

Apparently, he did exactly the same thing a year ago and failed to follow through. Unfortunately, this seems to have completely failed to either catch up with him or stop him from dragging the Apache Foundation's name through the mud for PR gains.

Creeps! (1)

NetServices (1479949) | more than 3 years ago | (#34754742)

Just the name WANDisco gives me the creeps!

IBM does not run Linux (0)

Anonymous Coward | more than 3 years ago | (#34755398)

> A majority of the changes in Linux are done by IBM paid employees

Nope, IBM only does about 2-3% of the development. There are thousands of contributors every release, and no one person/company does a majority of the work.

http://lwn.net/Articles/395961/

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>