On projects and their goals

By Jonathan Corbet
April 5, 2010

Recently, we have seen two projects come under considerable criticism for the development directions that they have taken. Clearly, the development space that a project chooses to explore says a lot about what its developers' interests are and where they see their opportunities in the future. These decisions also have considerable impact on users. But, your editor would contend, it's time to give these projects a break. There is both room and need for different approaches to free software development.

The Subversion project recently posted a "vision and roadmap proposal" describing where this popular source code management system can be expected to go in the future. The Subversion developers have made some clear decisions; these include not even trying to compete in the distributed version control system space, a reworked storage layer, rename tracking, better conflict handling, and more. The mission of the Subversion project is not to chase after the flashier distributed systems which are displacing it in a number of contexts; instead, Subversion will exist to serve the needs of users who feel the need for a simple tool with a centralized repository.

This announcement drew well over 100 comments on LWN, and similar numbers elsewhere. Quite a few of them were of the "here's a nickel, get a real SCM" variety; it seems that many see Subversion as old, unfashionable, and past its expiration date. Others were critical of Subversion's users, claiming that there's no reason why they couldn't move to a proper distributed system like all of the cool people have. Quite a few people, it seems, would be happy to see Subversion curl up and die; others think that the decision not to pursue distributed features will cause that to happen.

But there are plenty of distributed version control systems out there, a few of which have accumulated substantial user and developer communities. The Subversion developers are right to believe that they would be hard put to create a credible offering in that "market" at this point; they would have to create something which is demonstrably better than the existing systems, bearing in mind that those systems are improving quickly. Beyond that, there truly are large numbers of Subversion users who are mostly happy with what they have. Those users may have "look into distributed version control" on their long-term to-do lists, but, meanwhile, they have projects to manage. They are best served by a plan which calls for improvements in the Subversion they are using now.

Subversion is mature software. There will certainly be no shortage of things which can be improved in it, but its period of rapid development may be well behind it. There is nothing wrong with the developers saying so; in fact, there is much to commend there. Developers looking for fast-moving, distributed systems have a variety of offerings to choose from. Subversion, instead, will focus on what it does best: better serving the users that it has now. It seems entirely likely that there will be quite a few of them for some time yet.

[PULL QUOTE: Here, instead, we're told that users like the way things are now, and that trying to make changes is a mistake. END QUOTE] A very different discussion has surrounded the minor user interface changes planned for the upcoming Ubuntu 10.04 release. Here, instead, we're told that users like the way things are now, and that trying to make changes is a mistake. It's tempting to throw all of the complaints into the "bike shed" category, but this is a shed that Ubuntu users will be staring at all day long. These changes risk creating gratuitous differences between distributions and causing confusion in users who are used to finding their window buttons in a different place. Might not it be better to leave well enough alone?

Note the difference, though: while there is probably limited scope for innovations in the problem space that Subversion has chosen for itself, anybody who tries to argue that our desktop system usability problems have been solved will face a skeptical audience indeed. We have come a long way, but "usability" as a problem in general is far from solved. It makes sense to be conducting experiments in this area, especially for a distribution like Ubuntu, which has always had a focus on desktop usability. Other Ubuntu experiments - less intrusive desktop notifications, for example - have found their way into other distributions as well.

This line of reasoning can be taken farther: we desperately need more experimentation with usability in the free software space. We have spent years trying to catch up to proprietary alternatives; this work, for the most part, is done. At this point, we can focus with trying to match usability changes made by others, or we can try to come up with interesting new stuff of our own. Your editor clearly prefers the latter.

Given the scale of the problem, the biggest complaint with moving window buttons to the left might well be: why spend so much time and energy on such little things? We're not at the stage where we work for months to yield a 1% improvement; it's time to be a bit more bold. Projects like MeeGo seem much more interesting in this regard; those developers are seriously trying to rethink how specific groups of users will use their computers in the future. Android, too, has done some interesting work toward the creation of finger-friendly interfaces. And so on. That is the kind of experimentation we need to have.

Two other criticisms have been aimed at the Ubuntu changes: that user interface changes require the participation of human-computer interaction experts, and the top-down decision mechanism is not particularly community-oriented. On the first charge your editor - who made human-computer interaction the focus of his Master's degree work - has a bit of sympathy. But that claim also sounds vaguely reminiscent of the SCO Group's assertion that the Linux community could never have come up with an enterprise-class server operating system on its own; one should never underestimate what our community can do. In the end, the real key to usability is to pay attention to the users. Free software developers have a high degree of access to their users; those who take advantage of that access will have a higher chance of creating successful interfaces.

Beyond that, we do also have usability experts in our community.

On the second charge: undoubtedly Mark Shuttleworth's ability to direct Ubuntu by decree will be irksome to some. The "behind closed doors" nature of some Ubuntu development is also annoying and detrimental to the creation of a true developer community. On the other hand, it's a rare distribution which makes these decisions in a democratic way; even Debian doesn't hold general resolutions on window button placement. There comes a time when it's best to make the decision and move on; individual users can always fix things they don't like.

In summary: Ubuntu could certainly be more open about the changes it is trying to make and, perhaps, more open-minded about accepting input from its user community. But Ubuntu's work toward improving usability is desperately needed, and any interaction changes are certain to upset some users. Even if the specific change in question is not necessarily the best, experimenting with this kind of change needs to be done, regardless of the inevitable complaints.

More generally, every project has to have some idea of the problem it is trying to solve. In some ways, that's a far more important part of a project than any specific body of code or any specific developer. One of the best things about free software is that it's alive; it will evolve and, with any luck, be better tomorrow. A project's goals say a lot about how it can be expected to evolve. In your editor's opinion, both Subversion and Ubuntu have set worthwhile goals, and both seem to be trying to work toward those goals. These are good things; our community is richer for the existence of both.

to post comments

On projects and their goals

Posted Apr 5, 2010 21:56 UTC (Mon) by juliank (guest, #45896) [Link] (3 responses)

> even Debian doesn't hold general resolutions on window button placement

We could, but it needs a 2:1 majority according to Constitution 4.1.3, but
the Technical Comitte has to agree with a 2:1 majority as well.

On projects and their goals

Posted Apr 6, 2010 12:22 UTC (Tue) by error27 (subscriber, #8346) [Link] (2 responses)

80% of the 5000 people in this poll wanted the buttons moved back. That was before the close button was moved to the edge so I don't know if that would change the numbers.

It's good to do experiments with the UI but it would have been better to do it early on in the beta period instead of on actual users.

It seems like everyone recognizes that moving the buttons was a step backwards, but we've been told that later on we'll take two steps forward later. It would be easier to evaluate that if we could do the two steps forward right now instead of waiting six months.

To me, it's a crazy thing what Ubuntu has done here. Instead of talking about all the other things which have changed and improved people are just talking about the buttons.

Anyway, the button change doesn't even affect me and what do I know...

On projects and their goals

Posted Apr 7, 2010 9:32 UTC (Wed) by error27 (subscriber, #8346) [Link]

(BTW. The reason it doesn't affect me is not because I don't use Ubuntu, it's because I know how to fix it and didn't want to be told again).

I still think Ubuntu is awesome. That's another difference, is that the complaints about SVN are from people who want it to die and the complaints about Ubuntu are from people who want it be to be great.

On projects and their goals

Posted Apr 8, 2010 8:45 UTC (Thu) by aigarius (subscriber, #7329) [Link]

Important point - if you use any of the old themes, such as Human, the
buttons will stay on the right. The buttons are moved to the left *only* in
the new themes Ambiance and Radiance.

There was a bug initially that made the buttons jump for all themes, but it
has since been fixed.

With that in mind, I am glad about the feature as it gives people this
option, even if I personally do not like it at all.

The fact that Mark decides what goes into Ubuntu is one of the main
features of Ubuntu from the very start. He decided to put some naked ladies
on the desktop backgrounds in the early version, just because he likes
them. If you want to get more involved in the creation of your Linux distro
- go to Debian. If you want the defaults pre-selected for you by one person
and thus form a uniform and coherent whole - go to Ubuntu.

On projects and their goals

Posted Apr 5, 2010 22:16 UTC (Mon) by lmb (subscriber, #39048) [Link] (23 responses)

I think the SVN "controversy" highlights something quite different from the Ubuntu issue - the latter is something "everyone" has an opinion on, and it is very hard to technically measure.

Subversion, on the other hand, probably annoyed most people by a vision statement that implied it had a legitimate claim to be superior in those areas, which it doesn't - note that the latter found arguments (large binary blobs, among others) weren't in that statement, but that the claims it did make were at the expense of the "competition". It read like "DVCS: not simple to use, not controlled, don't support centralized work-flows". Of course that annoyed the hell out of DVCS users.

Further, "competition" in Open Source is a bit tricky. Yes, competition is good - exploring several paths is good. We can be thankful that the community is so large that it allows several to be pursued without weakening the overall results. But there's always also a cost to it, too (not just in development, but also user confusion about what to use and why); and when something is, after having explored many paths, is found to be technically inferior (except for smallish claims that could readily be incorporated into the "better" solution(s), but not vice-versa), there is a - arguably productive - annoyance at further waste of resources, that could be spent on something else. At that stage, "competition" is no longer perceived as good; and it should not be perceived as good unequivocally, since there are situations where it is, objectively, not beneficial.

That is also part of the discourse, and part of the "optimization" processes in the community, just like its ability to explore those different paths. It, of course, doesn't always succeed, and sometimes it yields a better understanding of why the concurrent paths still make sense. But consider EVMS2; consider egcs; consider the development in the area of cluster stacks; expanding common code in the Linux kernel, or file systems that have been abandoned over time; arguably, these convergence processes made the community stronger, too.

If you saw someone today touting FAT as a file system for all those who don't need all that fancy stuff, but as a general purpose fs outside a very narrow niche; or coming up with a mission statement for it, or for CVS, or trying to revive EVMS2, you'd probably be inclined to question their sanity too, would you not? ;-)

On projects and their goals

Posted Apr 5, 2010 22:58 UTC (Mon) by dlang (guest, #313) [Link]

competition is good, explaining why you are better than your competition is a necessary part of that competition.

however, you need to be very careful in what you say.

If it's true it needs to be said (but keep in mind that it may not be true after the next release of the competition)

Exposing weaknesses is good, even for the project who's weaknesses are being exposed. It gives the developers of that project a chance to either plan to fix the weakness, or to clarify their vision and say that they think other things are more important.

People do need to accept that a project may decide not to do something that you want, or to do something that you don't want. You can try to persuade them, you can fork the project, or you can move to another project, but you don't have the right to harass them about that decision forever (see the KDE4.0 release and the fact that people two years later are still picking on it as an example of what not to do). The Ubuntu issue falls in this category.

However, if you make claims about your competition that are not true, you should expect to be called on them.

For example, you can't make a statement about databases and say that MySQL doesn't have transactions and not expect to have a few dozen people correct you. You can state that the most common back-end doesn't have transactions. On the other side the MySQL people can't get away with making performance claims based on the transaction free back-end and capability claims based on the transaction-capable back-end (unless they make very clear that you don't get both from the same back-end) they will have many people call them on this.

The community has always responded rapidly to incorrect information. With the amount of FUD thrown our way from the outside, the responses have gotten faster and stronger. This is a good thing when the people making the false statements are companies like SCO, it's not as good when it's something like the Subversion vision statement. However I don't think that you can get one without the other.

On projects and their goals

Posted Apr 6, 2010 0:46 UTC (Tue) by neilbrown (subscriber, #359) [Link] (21 responses)

> It read like "DVCS: not simple to use, not controlled, don't support centralized work-flows".

Strangely I didn't read it like that. I went back to have a look and
yes, it does say that. In one line in the middle of a paragraph early
in a longer document. Only responding to that bit seems a bit narrow.

The bit that struck me was "Obliterate". That is something that is
anathema to DVCS. It simply isn't possible to remove something from
e.g. git history because there is no single place to do that.

If people want that and other 'central control' features, and clearly
people do, then a non-distributed VCS clearly has a place.

And I think classifying community members as "resources" is very
dehumanising. The community is not a 'cloud' that you can outsource
development to. It is a collection of individuals with different
values and interests and itches and relationships and ....

If there is any wastage (and I don't agree there is), surely it would
be among git, hg, bzr all trying to do the same thing, rather than svn
trying to do something different.

On projects and their goals

Posted Apr 6, 2010 3:40 UTC (Tue) by MattPerry (guest, #46341) [Link] (6 responses)

> And I think classifying community members as "resources" is very
> dehumanising. The community is not a 'cloud' that you can outsource
> development to. It is a collection of individuals with different
> values and interests and itches and relationships and ....

Yet they are indeed resources that contribute to the whole. They contribute resources such as code, bug reports, education, advocacy, marketing, and other general labor (bug triaging, for example). All of which works to improve the project and further its goals.

What's next? Finding a gentler word than "kill" for terminating processes? Let's not run amok with political correctness please.

On projects and their goals

Posted Apr 6, 2010 6:34 UTC (Tue) by neilbrown (subscriber, #359) [Link] (5 responses)

It isn't about political correctness. It is about understanding that
people are people.

Resources are (to me) things that you have some control over, and can
re-purpose from one task to another. In an army the personnel could
be considered resources, and could be used for digging ditches,
preparing rations, or building bridges - but only one at a time. In a
business paid developers might be resources that can be directed to
fix bugs or build features or educate customers as the need arises.

But in a community people are contributors who contribute or not as
they choose. If they stop working on one thing it is vaguely possible
that they will start working on a related but more widely useful
project, but I don't think it is likely. They are just as likely to
go surfing or read a book. To suggest that it is a "waste of
resources" when someone works on something of their own choosing seems
akin to suggesting that it is a waste of resources when someone goes
skiing. They are presumably enjoying themselves and probably learning
something and that is all to the good.

You suggest that "code, bug reports" etc are resources and I very much
agree there. If someone goes to the effort of creating value and that
value is not realised (e.g. if bug reports are ignored) then that is a
waste of resources (providing the cost of realisation does not
exceed the value). But if people choose not to try to create that
value, that is not a waste of resources.

On projects and their goals

Posted Apr 6, 2010 8:15 UTC (Tue) by pranith (subscriber, #53092) [Link] (4 responses)

Totally agree. I hate people being called resources even if they are being paid.

People as resources

Posted Apr 9, 2010 16:26 UTC (Fri) by giraffedata (guest, #1954) [Link] (3 responses)

If someone actually refers to a human being as a resource, that's dehumanizing and wrong. But what people are really calling a resource is the potential of a person to do some work for the project. Calling that anything but a resource makes it harder to talk about in conversations about resources in general.

If someone really forgets that there's more to a person than his potential to do work for the project, that's a problem, but you can have a conversation about the resource associated with a person while still being aware that there's an actual person involved.

People as resources

Posted Apr 9, 2010 22:27 UTC (Fri) by neilbrown (subscriber, #359) [Link] (2 responses)

Resources are things you own or have some control over. People's time is not a resource until they give it to you (by doing work) or offer it to you. Until then it is only potential.
I think that in your conversations you should make a clear distinction between resources, which can be wasted, and potentials, which at worst may not be realised. I think they are very different things.

People as resources

Posted Apr 10, 2010 20:19 UTC (Sat) by giraffedata (guest, #1954) [Link] (1 responses)

Resources are things you own or have some control over. People's time is not a resource until they give it to you (by doing work) or offer it to you. Until then it is only potential.

To the extent that a project leader can expect some people to offer their time, the leader has control: he can accept or refuse the time. Of course, there's a debate to be had over whether he can expect the offer, which means whether that time is a resource.

I think that in your conversations you should make a clear distinction between resources, which can be wasted, and potentials, which at worst may not be realised. I think they are very different things.

In planning conversations, I don't see how they're different at all. If I'm trying to decide whether to use C or Ruby in a project, I might determine that I can generate more code with C because more volunteers will be willing to work in C and therefore I have more coding resources available to me on the C path. It doesn't make any difference whether I'm entitled to any of those C coders' time. If I go the Ruby route, I'm wasting the C resource as much as if I spend the project's bank account on a party instead of an FTP server for the project.

The reason to use the word "resource" for volunteer potential and bank account alike is that they're fungible. Someone might point out that if I work in Ruby, Google will throw in $5000. I certainly don't want to conclude that I have more resources available on the Ruby path because I'm not calling the volunteer time a resource. I have to do some careful analysis to see which path gives me more total resources.

People as resources

Posted Apr 11, 2010 8:19 UTC (Sun) by neilbrown (subscriber, #359) [Link]

I pretty much agree with most of what you write, but I still think there is a distinction worth making. Maybe I should have focussed more on the word "waste" than the word "resource". It is where you start talking about "waste" that we part company.

Try this: ask yourself the hypothetical question "Resources are being wasted, what can I do about it?". Think about your emotional response, and the style of practical responses that occur to you.

Then repeat with a different question "Potential is going unrealised, that can I do about that?".

To me, and I don't think I'm completely atypical, the former leads to thoughts of stopping something, while the latter leads to more productive thoughts of starting something. The former can lead to being annoyed (for the OP at least - Hi Lars!). The latter would lead to feelings of being supportive and encouraging.

I would describe your hypothetical choice between C and Ruby as a question of deciding how best to realise (or "tap") a potential.

Try this last hypothetical: "The talent and experience of the SVN developers is a potential that is not being fully realised. How can I best help realise more of what I see as their potential?".

Assuming someone agrees with the premise (I have no opinion on it), I'm sure they could think of lots of ways forward. Of course it would be more work then posting on a third party web forum :-)

On projects and their goals

Posted Apr 6, 2010 4:12 UTC (Tue) by lambda (subscriber, #40735) [Link] (10 responses)

Actually, you can't really "obliterate" in Subversion (or any other centralized VCS) either. People can still have checkouts of old versions on their machine. I can't be the only person who, due to various limitations of Subversion (such as lack of "git stash" functionality, and how slow it is to switch between branches), would frequently have several checkouts at once, along with a directory full of patches that might not be ready to apply yet, or might be an idea that never went anywhere that I might try to revive later. And some of those checkouts would eventually go stale, perhaps for years. Unless you have some way of tracking what developers have checked out on their machines, you can't really obliterate old revisions any better in a centralized system than in a DVCS.

What you can do, in either system, is rewrite the history on the official server copy. Then, in the DVCS, you have people make fresh clones, which won't share history. If people have stale copies on their machine, that's their responsibility; if it's such a liability that you must delete all stale copies, then you will need to have IT come and scan all developers machines for the offending code whether you're using a centralized system or a distributed one.

Well, you can... just not with SVN...

Posted Apr 6, 2010 6:46 UTC (Tue) by khim (subscriber, #9252) [Link] (9 responses)

And some of those checkouts would eventually go stale, perhaps for years.

They can go stale with SVN, but not with P4. Unlike SVN P4 keeps track of all checkouts on server (thus avoiding .svn madness) and if the client is not used for some time P4 admin will ask you to remove it. Plus server knows if you've checked out the obliterated file or not. And company can enforce the policy that checkouts can only go to NFS share - then files can be tracked even there.

In short: it's hard to make 100% reliable "obliterate" feature (you can always use your phone to take the photo of obliterated file and it's kinda hard to prevent that unless you are working in prison), but centralized VCSs are 100 times better then DVCS here...

Well, you can... just not with SVN...

Posted Apr 6, 2010 18:00 UTC (Tue) by ebiederm (subscriber, #35028) [Link] (8 responses)

I can not even fathom the use case that would be so important, that someone would optimize for being able to destroy all traces of time consuming expensive work.

Were you talking rhetorically or is there some case where obliterate is the key feature needed from a version loss^Wcontrol system?.

Well, you can... just not with SVN...

Posted Apr 6, 2010 18:27 UTC (Tue) by mrfredsmoothie (guest, #3100) [Link]

Code w/ comments which violate company policies (e.g., hate speech);

Code which divulges proprietary company information (e.g. trade secrets);

Code which divulges information the company is not allowed to divulge for regulatory reasons (e.g. Protected Health Information or sensitive financial data).

That was just 3 off the top of my head, took < 30 seconds. I'm sure there are many more.

Well, you can... just not with SVN...

Posted Apr 6, 2010 19:20 UTC (Tue) by foom (subscriber, #14868) [Link] (6 responses)

I have needed to destroy information from an SVN repository once. Someone committed stuff
which could not be left available, for legal reasons.

Despite not officially having support for such a thing, it was not too difficult to do manually. The
data was removed from the central repo, so if you tried to get an old revision, you got an empty
file, and as soon as people updated their checkouts, it'd be removed there. The clients just
picked up normally from the modified repository without a hitch.

Doing the same with a DVCS would be trickier: you need the explicit cooperation from all users
and need to proactively notify everybody that trunk has been rebased and so they need to rebase
all their branches and force pulls. (and also implicitly, that they should go look for the thing that
was removed to see what was so important as to require breaking everything).

Whereas with SVN, just normal user behavior of updating periodically will cause the data to
naturally disappear without having to bring undue attention to it.

To be fair, I don't think that was ever a design goal of SVN, they just happened to not put
sufficiently paranoid checksumming in it. But it is convenient. :)

Well, you can... just not with SVN...

Posted Apr 7, 2010 21:04 UTC (Wed) by lmb (subscriber, #39048) [Link] (3 responses)

One can, of course, design a DVCS which propagates "poison pills" for changesets (cryptographically signed, if needed, by the one authority that is allowed to), that in the normal course of action removed the offending changeset as they propagate.

Removing the changeset from the history through "rebase-like" can also imply that clients can't pull+merge, but would be forced to clone new.

That, then, requires active intent on the users's side to break, just like SVN right now. Yes, this is more tedious to _implement_, but it need not be more visible to users.

(Of course, none of these addresses outdated working directories nor backup files an editor may have created; if you're worried about legal compliance, you need to scan for the content and destroy it, actively. Regardless of SCM used.)

Well, you can... just not with SVN...

Posted Apr 7, 2010 21:42 UTC (Wed) by foom (subscriber, #14868) [Link] (2 responses)

An explicitly handled poison pills sounds like a quite reasonable way to implement the obliterate
feature in a DVCS. But nobody has done it, yet.

It (like the other features being discussed in this thread) is an important use case that seems to be
widely disparaged by the DVCS crowd as something nobody could ever possibly have a use for. So
it's really nice that Subversion has a goal of catering to these use cases that nobody else seems
interested in even *thinking* about.

Well, you can... just not with SVN...

Posted Apr 8, 2010 16:09 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (1 responses)

A "poison pill" that the poisonee has to swallow willingly, in full knowledge what it is, is kind of pointless for forcing the deletion of certain unwellcome contents... plus won't afect any copies floating around.

Yes, it would be excellent if you could remotely destroy all traces of some secret after the cat is out of the bag... but that just can't be done. Get over it.

Well, you can... just not with SVN...

Posted Apr 8, 2010 21:30 UTC (Thu) by foom (subscriber, #14868) [Link]

I see you don't understand the use case. That does not mean it's not real.

What I'm talking about is within a company, where there is some amount of central control. A
poison pill that the poisonee has to agree to is *not* pointless, if it is processed automatically
and allows the user to not care that it happened. The agreement would happen ahead-of-time,
when the clients are setup to trust the central repository.

Of course it's not possible to (remotely or otherwise) destroy all traces of information. Your
mistake is jumping from that true statement to the suggestion that it's pointless to do anything
at all. And that's simply not a supportable jump. Yes, an Evil User could intentionally save a copy
and Do Evil, but in a corporate environment where you hope you can trust everybody, it's often
quite sufficient to simply avoid explicitly tempting people to do something bad.

At the *very least*, I need to stop distributing the data (that is: remove it from the central
repository). And just that alone will cause significant user pain if everyone's using git. Everyone's
branches and working copies need manual intervention to clean up. Not a fun state to be in.
Contrast with SVN, which implicitly trusts the central repository, and just goes with the flow...

Well, you can... just not with SVN...

Posted Apr 8, 2010 13:43 UTC (Thu) by jengelh (subscriber, #33263) [Link] (1 responses)

>I have needed to destroy information from an SVN repository once. Someone committed stuff which could not be left available, for legal reasons.

There we are again. Review is _golden_, and the git-style "please-pull" model wins. You don't even get to have stuff merged that is obviously not ok (such as hate comments as a parent post described). And if you happen to have commit rights to the central location (in other words, being the maintainer), well, make it company policy that everything must have been reviewed before merging/pushing out.

Well, you can... just not with SVN...

Posted Apr 8, 2010 16:16 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Mistakes happen even with the utmost care, and have to be corrected after the fact. It can be done in git (using git filter-branch, aptly called "the nuclear option to history rewriting" by Pro Git). That doesn't mean it should be a streamlined command, as it will be used very rarely (if not, rethinking your workflow is in order, IMHO).

On projects and their goals

Posted Apr 6, 2010 6:49 UTC (Tue) by lmb (subscriber, #39048) [Link]

Neil, yes, there are some features SVN can do (or, as the case may be, pretend to do) better. "Obliterate" is an interesting example of this; DVCS highlight how difficult this is much better than centralized setups. However even in the latter, check-outs can exist, people can have made private copies etc; whereas in the former, of course one can strip changesets from history on the "central" and "official" repository too. (Yes, that will trigger a complete refresh, but it can be done if users follow the process - if they deliberately don't, SVN wouldn't help either.)

Yes, I also think that git/hg/bzr create waste through duplication, and it would be my hope that at least one of the projects falls out of favor. (People are free to disagree with this hope. ;-)

The pleasure people take from spending their time on "whatever", yes - fun-driven, intrinsic motivation from flow-experiences and learning. Still, as soon as they "go public" (with a mission statement, no less), they have opened the field up for discussion. I'm quite sure very few people would have objected if the message had been "SVN is fun to hack on and we'll continue to do that" (or "There's still so much data out there that a migration isn't feasible", or any number of good reasons); I believe what truly sparked the responses was the perception of a "slight" to DVCS. People can be touchy.

(On the topic of touchy misunderstandings, I wasn't actually intending to classify _people_ as resources, but the time/money/effort those people chose to invest, for whatever reason, and which they can repurpose with some control. I apologize if that may have come across differently.)

On projects and their goals

Posted Apr 6, 2010 23:48 UTC (Tue) by vonbrand (subscriber, #4458) [Link] (1 responses)

It might be just one line, but it is a central part of the whole SVN coment. The punch line, if you will.

On projects and their goals

Posted Apr 7, 2010 2:35 UTC (Wed) by neilbrown (subscriber, #359) [Link]

Hmmm... maybe that is a valid approach after all.

An untruth, left unchallenged, is often widely believed.

On projects and their goals

Posted Apr 5, 2010 22:56 UTC (Mon) by grantingram (guest, #18390) [Link]

I'm not sure this is informative but I thought this was a really good article from our editor. LWN is the place for balanced and thoughtful writing... so thanks!

On projects and their goals

Posted Apr 6, 2010 3:36 UTC (Tue) by eru (subscriber, #2753) [Link] (3 responses)

Developers looking for fast-moving, distributed systems have a variety of offerings to choose from. Subversion, instead, will focus on what it does best: better serving the users that it has now. It seems entirely likely that there will be quite a few of them for some time yet.

Indeed. Version control systems can live a very long time, because they hold long-lived data, and migrations are inconvenient and risky, especially in large organizations with thousands of developers. I know of one big company that is gradually moving to Subversion as its standard version control system. The system it is mostly replacing is an in-house variant of SCCS that dates back to the early 1980's!

On projects and their goals

Posted Apr 7, 2010 6:52 UTC (Wed) by Yenya (subscriber, #52846) [Link] (2 responses)

I am not sure whether even Subversion can count as a "long-term" solution.

A month ago I have tried to make a modification to a relatively old project which I wrote, and which did not need maintenance until then. It had the source code in a SVN repository. I have discovered that current SVN cannot access the repository of this project because of repository format changes. So instead of spending time trying to determine which intermediate version of SVN (and probably BerkeleyDB) I should compile to access pre-1.0 SVN repository, I have just ditched the project history altogether and imported the current snapshot to Git. I am well aware that five years from now I may have the same problem (but then, reading the SVN mission statement, they discuss a yet another repository backend there, so SVN would not help either).

On projects and their goals

Posted Apr 7, 2010 8:03 UTC (Wed) by foom (subscriber, #14868) [Link] (1 responses)

SVN has been extremely backwards compatible: there hasn't been an incompatible repository
format change since version 0.34 in December 2003. (And 0.28 before that). Those were done
when svn was basically still being designed, pre-1.0. It seems a bit overreaching to fault them for
dropping compatibility a couple times in their pre-release infancy!

See:
http://svn.apache.org/repos/asf/subversion/trunk/CHANGES

It has links where you can grab the source for the old versions, even.

On projects and their goals

Posted Apr 7, 2010 10:05 UTC (Wed) by Yenya (subscriber, #52846) [Link]

If I can remember correctly (I no longer have the said SVN repo), it said that the version 1 repo is not supported, only versions 3 to 5 are. And yes, 2003 is probably the correct time frame. The GP post said something like migrating repo from early 1980s, which I doubt would last so long with either SVN (the new repo format is already being discussed) or Git. The later is more feasible, though, because the data (commits and trees) are in plain text form.

On projects and their goals

Posted Apr 6, 2010 9:56 UTC (Tue) by modernjazz (guest, #4185) [Link]

Hear, hear!

On projects and their goals

Posted Apr 6, 2010 10:41 UTC (Tue) by ewan (guest, #5533) [Link] (10 responses)

It's not the "behind closed doors" nature of development that's the problem, notably other distributions (for example RHEL) that are even more 'closed' don't get this sort of flak. The problem is doing development in secret while claiming to be a community distribution. What irks people is being deliberately mislead.

On projects and their goals

Posted Apr 6, 2010 13:17 UTC (Tue) by kh (guest, #19413) [Link] (4 responses)

The (constant) Ubuntu complaints are interesting to me in that it seems the loudest complaints and cries of hypocrisy come from people who not only do not contribute to Ubuntu, but are not even really users. I lost count of the number of times I have read complaints that Ubuntu will only be around so long because of financial concerns from people who admittedly do not use Ubuntu (at least as their primary distribution.) It says a lot about the core Ubuntu team that they remain as thick skinned and patient as they do.

On projects and their goals

Posted Apr 6, 2010 14:14 UTC (Tue) by seyman (subscriber, #1172) [Link] (2 responses)

> I lost count of the number of times I have read complaints that Ubuntu will only be around so long because of financial concerns from people who admittedly do not use Ubuntu

Keep in mind that the financial health of Canonical/Ubuntu affects the entire Linux ecosystem, not only Ubuntu users.

On projects and their goals

Posted Apr 6, 2010 16:50 UTC (Tue) by rsidd (subscriber, #2582) [Link] (1 responses)

>Keep in mind that the financial health of Canonical/Ubuntu affects the entire Linux ecosystem, not only Ubuntu users.

Only to the extent that Ubuntu users are now a large fraction of the ecosystem. How would non-Ubuntu users be worse off, were Canonical to vanish today, than they were pre-Ubuntu?

On projects and their goals

Posted Apr 6, 2010 17:38 UTC (Tue) by seyman (subscriber, #1172) [Link]

> Only to the extent that Ubuntu users are now a large fraction of the ecosystem.

Sounds sufficient that they be allowed to express their worries (OP heavily implies this isn't the case).

> How would non-Ubuntu users be worse off, were Canonical to vanish today, than they were pre-Ubuntu?

The non-Ubuntu users will be the ones who have to explains to former Ubuntu users that the distribution that they were using was a commercially-backed one, not community-backed (although I assume recent events have opened their eyes). They will be the ones who have to convince canonical customers (the paying kind) that they should keep on using FLOSS and not go back to the "safe choice" and they'll be the one who have to convince the IT media that Ubuntu != Linux and that Canonical's downfall doesn't mean the Linux ecosystem itself isn't dead.

On projects and their goals

Posted Apr 6, 2010 16:33 UTC (Tue) by ewan (guest, #5533) [Link]

the loudest complaints and cries of hypocrisy come from people who not only do not contribute to Ubuntu, but are not even really users.

Well that's hardly a shock is it? That people that either don't like the distribution, or don't approve of the way the project is managed might choose to not use or contribute to it.

On avoidance of alleged hypocrisy

Posted Apr 6, 2010 16:17 UTC (Tue) by robla (subscriber, #424) [Link] (3 responses)

So, if person A is a jerk and proudly declares that they are a jerk, and
person B is less of a jerk, but claims to be good person, then clearly
person A is less irksome than person B?

As a community, we spend an awful lot of energy attacking those that almost
get it right. It's not a flattering aspect of our culture.

On avoidance of alleged hypocrisy

Posted Apr 6, 2010 17:01 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (2 responses)

It's about managing and communicating expectations. Set expectations high and fail to meet them in a personal relationship or in a team setting and you will have disappointed someone. Do that in a business with a paying customer and not only do you disappoint but you lose a customer, and the income.

Canonical's problem with setting high expectations on community participation and failure to communicate a design roadmap where these UI changes make sense in context are not insurmountable. I seriously doubt a significant number of people are going to walk away over button placement. I also doubt that they are going to just let it go either..as they are emotionally invested in the Ubuntu desktop experience...and that is exactly what Canonical wanted in the Ubuntu community..emotional investment.

But I have to wonder, does Canonical do the same with its paying support customers and business partners? Set expectations too high and fail to deliver? You can't get it "mostly" right in business.. you have to execute and you have to deliver on your promises. If you under deliver on an over promise when money exchanges hands, that's a significantly more difficult situation to repair then what we are seeing in the dust up over the unfathomable decision making for moving the window buttons.

-jef

On avoidance of alleged hypocrisy

Posted Apr 6, 2010 17:56 UTC (Tue) by robla (subscriber, #424) [Link] (1 responses)

Did Canonical set expectations too high, or did everyone else have
expectations set too high in spite of Canonical setting them appropriately?

On avoidance of alleged hypocrisy

Posted Apr 6, 2010 18:22 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

That's a very good question. I think what's happened here is there is a conflict in the general messaging about the role of community input in Ubuntu development and the distinct lack of messaging about how community participate in the design process in particular.

The design process is discordant with established patterns of gathering feedback in decision making Ubuntu has been using. Canonical has built up expectations on driving community feedback early for a release at at UDS events. Were design roadmaps for Lucid discussed at the last UDS? Was there even a discussion about a usability test plan if Canonical is sincere about wanting quantifiable usability data about design changes?

If you look back at all the discussions at UDS.. things like the discussion over dropping gimp and adding pitivi...that discussion was done in the open before the changes went into effect. The window button ordering was probably about as impactful (and heated) as dropping gimp..but no UDS discussion...no reasoning put forward that makes consistent sense with a set of understood benefits even if its not agreeable to opponents of the change.

The design process leading up to the button change stands outside of the established expectation that plans for impactful changes for a release get discussed at UDS. Finally telling users that the design team is looking for quantitative usability testing data from end-users several hundred comments deep into a bug report about the change is NOT the way you do data driven design.

If Shuttleworth is serious about wanting data and using crowdsourcing mechanisms to construct viable usability test methodologies, as he finally got around to saying in the bug report 20 days after it was filed, then he sure as hell should have communicated at UDS to give everyone a heads up about the role the design team wants the community to take.

-jef

On projects and their goals

Posted Apr 8, 2010 13:46 UTC (Thu) by jengelh (subscriber, #33263) [Link]

What irks me more is that people who are being misled don't react to it, e.g. vote with their feet.

On projects and their goals

Posted Apr 6, 2010 15:44 UTC (Tue) by iabervon (subscriber, #722) [Link] (16 responses)

There's nothing that a centralized VCS can do that a distributed one couldn't do, aside from making life more difficult for non-central users (that, is you can obliterate something with either, but users of a distributed system will only be minorly inconvenienced in trying to ignore the fact that you did this). But there's a substantial number of things that SVN does currently take care of that no distributed VCS currently does. I think it's a good policy on the part of the SVN developers not to fight for the users who would be happier using another system, but rather being helpful to the users whose best choice of the current options is SVN.

I expect that a time will come when nobody uses SVN any more, and the developers will have gone on to work on different things. Probably every infrastructure project is the same way, however, and that's not a reason not to work on them while they're useful.

On projects and their goals

Posted Apr 6, 2010 22:17 UTC (Tue) by vonbrand (subscriber, #4458) [Link] (15 responses)

I'm genuinely interested in what things SVN can do that the current breed of DCVS systems can't.

On projects and their goals

Posted Apr 6, 2010 23:32 UTC (Tue) by iabervon (subscriber, #722) [Link] (14 responses)

Allow a user to prepare a commit that includes some directories without disclosing the contents of those directories to the user (where the user leaves them unchanged relative to some commit).

Allow a user to defer downloading the content of some files which do not compress well (even against the rest of the project) until that content is actually required.

Support users communicating with each other the intent to change a particular unmergeable file in a particular branch of a particular repository such that a user can be sure that it will be unnecessary to resolve merge conflicts in order to push changes to that branch of that repository. (And other users may make changes to these files, but will not be unaware that they may be forced to redo their work because of a conflict.)

There's also the issue that, if a project has an enormous SVN installation already, such that reading the whole thing is impractically slow, DVCSes currently don't support only importing (and reading) the portion necessary for some particular operations.

There are also sites using SVN as a distribution mechanism and namespace for large binary files, where they want to keep a history of what was there. Sure, SVN is the wrong tool for the job, but a DVCS is even more wrong, and they should be moving, when they move, to something else entirely.

There are probably more odd usages that haven't come up yet because the users haven't tried anything but SVN. It's generally nothing that can't be solved, but they require development targeted at usage that would be bad practice for software development but may be appropriate or even required for other sorts of content.

On projects and their goals

Posted Apr 7, 2010 0:13 UTC (Wed) by dlang (guest, #313) [Link] (7 responses)

quote: Allow a user to prepare a commit that includes some directories without disclosing the contents of those directories to the user (where the user leaves them unchanged relative to some commit).

explain this a bit more please.

deferring downloading of some files can be done with git narrow/shallow clone options

as for this one:
Support users communicating with each other the intent to change a particular unmergeable file in a particular branch of a particular repository such that a user can be sure that it will be unnecessary to resolve merge conflicts in order to push changes to that branch of that repository. (And other users may make changes to these files, but will not be unaware that they may be forced to redo their work because of a conflict.)

how does SVN do this? isn't all the communication between users done outside of SVN? or are you referring to locking when you check something out?

your next point: There's also the issue that, if a project has an enormous SVN installation already, such that reading the whole thing is impractically slow, DVCSes currently don't support only importing (and reading) the portion necessary for some particular operations.

has nothing to do with SVN being better, merely with it being painful to switch away from SVN

re: large binary files, how large does SNV support? I thought I saw comments here indicating that it also has a fairly small limit.

On projects and their goals

Posted Apr 7, 2010 2:04 UTC (Wed) by iabervon (subscriber, #722) [Link] (6 responses)

First one: there are projects that want to have some files that some users can't read in the same directory as other files that the user can modify (and make commits to change). SVN doesn't need the user to be able to read all of the files in a revision in order to create the revision, simply because the client side doesn't need the information and the server side has it. Git (for example) could deal with this, but gets upset about not having access to all of the content in the commit.

Second: Last I checked, git's shallow clone support wasn't sufficient to let you get the arbitrary set of blobs that you actually care about, and there's only narrow checkout, not narrow clone. Furthermore, you can't clone the whole history, figure out (from the commit messages and changed files) which blobs matter to you, and download those particular blobs.

Third: Locking. As I just mentioned in http://lwn.net/Articles/382416/, there are situations where development tasks can't be parallelized with the available tools, and users want to avoid wasting their times by getting (advisory) locks and making sure that the user who got the lock doesn't have to redo their work. SVN offers mandatory locks, which is not optimal for users that choose to ignore them, but better than doing pointless work accidentally.

Fourth: I didn't say that other systems weren't better than SVN. I said that there were things that other systems didn't deal with as well as SVN does. One of these is your existing SVN server being unable to produce the whole history in a timely fashion.

Re file size: I've never stored a large file in SVN, but I've heard of people trying to switch to git and having problems, and it turning out that what they were version-controlling was video recordings that they were editing, and they had a many-TB fileserver and a laptop that could store maybe three copies of the video. I think it was SVN that they were using, but I may be mixing up stories.

On projects and their goals

Posted Apr 7, 2010 20:06 UTC (Wed) by vonbrand (subscriber, #4458) [Link] (5 responses)

Re: "Unreadable files": I just fail to see the point. If I develop, I need to see what I'm working with. Else, I don't need it, and shouldn't have to include it in my commits.

Re: "Shallow clone in git": Right, git is designed to work having all history available. Disk space is cheap nowadays... if it becomes a real problem, it could be ~~kludg~~worked around, I suppose. Not a show killer to me.

Re: "Locking": Sorry, but this is needed in SVN because there is a central repository (lest you lose all version control). With a DVCS, each one works in her own space, and integration (and conflict resolution, etc) don't need to happen during development.

On the others, I'm unable to comment.

On projects and their goals

Posted Apr 7, 2010 20:23 UTC (Wed) by njs (subscriber, #40338) [Link] (2 responses)

Yes, sure, we all know that most people on LWN don't need these features, that's why git is so successful :-). But all that's being claimed is that other people -- not you -- do. Is that really so unbelievable? :-)

BTW, I used to scoff at locking too, but it actually does make sense for files where merging is simply not possible. (Think PNGs, or, like, CAD documents with an undocumented format and no vendor-provided merge tool.) Any simultaneous development requires you to throw away one side and re-do that work from scratch, so delaying integration is a terrible idea.

On projects and their goals

Posted Apr 8, 2010 16:24 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (1 responses)

I do know my set of requirements isn't the same as everybody else's, that is precisely why I'm asking.

What I'm trying to say is that such coordination among developers can't be just done by the tool: If we both start work on some unmergeable file, and then you lock it, I won't become aware of that until I try to lock it myself (perhaps much later, after much work has been wasted). This has to be handled in some other way, AFAICS.

On projects and their goals

Posted Apr 8, 2010 17:10 UTC (Thu) by farnz (subscriber, #17727) [Link]

Normally, the tool support for locking is good enough; working copies of files that need locking are read-only, so that when you come to save, the underlying OS says "no, file is read-only". You then get the lock before you continue working.

What's more, most tools don't even let you start work before you make the file in your working copy read-write. Because it's part of your working copy, your training makes you do that via the version control tool, which grabs the lock for you. Thus, normally it's a matter of seconds between opening a file with intent to work on it, and the tool telling you that you've forgotten a workflow step.

On projects and their goals

Posted Apr 8, 2010 16:44 UTC (Thu) by jschrod (subscriber, #1646) [Link] (1 responses)

You should not that version control systems are used for more purposes than software development. These other use cases have constraints that make your counterpoints invalid; for them you *need* support of processes that include locks, or unreadable files.

On projects and their goals

Posted Apr 12, 2010 1:05 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Yes, I'm interested in uses other than "software development". But just stating that there are applications that require some strange features doesn't help understanding if they are really needed, just an artifact of the tool currently being used, or even "that's how we are used to do it since way back when".

On what SVN can do that DVCSes can't

Posted Apr 7, 2010 0:36 UTC (Wed) by vonbrand (subscriber, #4458) [Link] (5 responses)

Allow a user to prepare a commit that includes some directories without disclosing the contents of those directories to the user (where the user leaves them unchanged relative to some commit).

I fail to see any use for this... said commiting user is (by definition) unable to check if the result works, or even makes any sense.

Plus if you distrust your users with commit rights that badly, you should rethink your workflow and organization assumptions very carefully indeed.

Allow a user to defer downloading the content of some files which do not compress well (even against the rest of the project) until that content is actually required.

Good point. But that kills one of the advantages of DVCSes, any operation can be done offline. Plus disks are getting cheaper (I very much doubt I can really fill a terabyte with meaningful data I'll ever use), and being able to get said contents at leisure when doing the first clone, and getting it from the nearest clone (not necesarily the "home repo") does offest that somewhat.

Support users communicating with each other the intent to change a particular unmergeable file in a particular branch of a particular repository such that a user can be sure that it will be unnecessary to resolve merge conflicts in order to push changes to that branch of that repository. (And other users may make changes to these files, but will not be unaware that they may be forced to redo their work because of a conflict.)

I don't follow you here. What do you mean by "unmergeable files"? If branches are laid out right, "unmergeable files" on the same branch touched by different developers just can't arise (the only possibility for merge conflicts in git is between branches, when you decide to merge them). And with git, once you resolve a particular conflict on a particular branch, it just can't arise again there. The merge algorithms in git have been tuned to minimize noise conflicts, and it is even possible to use ones' own if need be.

There's also the issue that, if a project has an enormous SVN installation already, such that reading the whole thing is impractically slow, DVCSes currently don't support only importing (and reading) the portion necessary for some particular operations.

This was handled e.g. by X.org by breaking up the all-in-one monster into manageable pieces (which they wanted to do anyway before migrating, AFAIU). Different tools, different ways of using them right. In a sense, this is relevant only for interacting with repositories in legacy VCSes or for (shortish?) transition periods, it is not a downside of DVCSes per se.

The others are arguably (mis)uses of a VCS, there is no reason to cater for them with any DVCS; as you correctly state, they should probably use other tools.

On what SVN can do that DVCSes can't

Posted Apr 7, 2010 1:44 UTC (Wed) by iabervon (subscriber, #722) [Link] (4 responses)

(1) An organization may have a secret key included in the project, which is used for making a signed release, but which developers are not allowed to have access to. It doesn't make sense in open-source setups, and only sort of makes sense to arrange that way in a closed-source organization, but there are organizations that do this. I never said that these use cases were a good idea, but there are sites that work like this.

(2) Try putting all of the CAD models of all the revisions of all of the parts of a car on every single engineer's workstation. A workstation could handle the recent revisions of all of the parts that are important to the particular engineer, but that's a tiny fraction of the whole history, particularly because the files don't compress well, even when there are (semantically) small changes between different revisions of the same part. Furthermore, it wouldn't be hard to download all of the commit messages and enough of the revisions of enough of the parts to be able to work offline.

(3) The "unmergeable files" are binary files for some closed-source program, often one where there aren't known diff/merge algorithms or an easy way of looking at multiple different options and preparing a merge result. The problem isn't branches, it's that there's just no way available to do a three-way merge of versions of a file that isn't more work than just starting over and making your modification again.

Obviously, git is perfectly sufficient for reasonable software development as it is. But there are a number of important uses of version control for applications that aren't software. Companies designing cars or circuit boards can't do it entirely in easily-merged text-based files that compress well, diff meaningfully with current tools, and generally are what you'd recognize as "source", but which are, nonetheless, the preferred form for making changes to what they work on.

On what SVN can do that DVCSes can't

Posted Apr 7, 2010 3:40 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

part of this depends on if you are looking for ways to make things work, or looking for ways that they won't work.

there were two cases mentioned as "git can't do this" that I see as reasonably easy to deal with

for your #2 (secret key) you could do a publicly accessible repository without the key, then a private repository that uses the subproject feature to refer to specific states in the public tree and also has the key in it.

I'm not finding it, but someone mentioned circuits changing and the effort to re-route the circuit board when schematic changes were made. This could be a similar thing, one project where multiple people can change the schematic, but then someone (project lead, whoever) decides that this version of the schematic is likely enough to be useful to have someone spend the day routing the board. that version of the schematic would be checked in as a subproject to the repository that contains the board routing.

or you could just only do the routing work when assigned to do so, rather than after any change.

an engineer's workstation with a TB of space could probably handle the cad files without much trouble. but is that really what the person cares about? In reality you don't have an engineer who cares about every detail of every part on the car. You have the engineers working on the axle who care about all the details of that, but the engineer working on the car as a whole is going to select axle version X and use it (ore more likely, axle model X, with specific external attachments, and variations of that model are invisible to that engineer)

This sounds like another perfect case for subprojects.

your final case (propriatary formats that can't be diffed) is a case where any VCS can do no better than storing copies of each one, but it may not be appropriate for these files to be in the VCS in the first place. Just like datbases have the concept of large objects where the database contains how to get to the object, not a copy of the object itself, the VCS may be better off storing such things elsewhere and just keeping a link to it. Git doesn't do this today, but it's been discussed, just nobody has wanted the feature badly enough to code it (or pay someone else to do so)

On what SVN can do that DVCSes can't

Posted Apr 10, 2010 13:17 UTC (Sat) by jpnp (guest, #63341) [Link] (1 responses)

> (propriatary formats that can't be diffed) is a case where any VCS can do no better than storing copies of each one, but it may not be appropriate for these files to be in the VCS in the first place. Just like datbases have the concept of large objects where the database contains how to get to the object, not a copy of the object itself

Many binary formats can be usefully diffed using a binary diff algorithm with large savings in storage space over separate files. SVN has done this from the start in its storage system (built on xdelta IIRC). The point with binary files is that the diffs have no semantic meaning and are not useful for merging.

While some DB systems do offer the ability to store BLOBs externally, all that I can think of also allow BLOBs to be kept within the DBMS, and this is widely used too as there are management/tooling advantages to one cohesive system.

Just because git and other DVCSs have been a phenomenal success for the OSS project use-case, and many developers are keen to leave SVN behind, doesn't mean that there isn't a place for the technology. Just because git could be made to do it, SVN isn't the better fit for some use cases.

In my professional job I have just moved a development project from SVN to mercurial. Most developers where sceptical as they only have experience of CVS & SVN, but I think it'll be worth it. However, I also have projects which are storing scientific data in a VCS, that's just as valid a use for version control (we no longer call them Source Code Control Systems, do we), and I would not consider moving that away from SVN.

On what SVN can do that DVCSes can't

Posted Apr 12, 2010 1:09 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

One thing to consider is that it is better all around to use one tool than having each one be up to snuff with several.

On what SVN can do that DVCSes can't

Posted Apr 8, 2010 16:27 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

(1) Secret keys (or such confidential data) have no place in a shared repo. They should be way better protected than "regular files" at the repo servers.

user interface experimentation

Posted Apr 8, 2010 8:38 UTC (Thu) by pkalliok (guest, #63969) [Link] (1 responses)

While tinkering with button placement can be seen as "experimentation" with user interfaces, I'd like to point out that there are other frontiers where UI innovation is more clearly made in the open source community: for instance, wm's like ion3 and xmonad come to mind.

user interface experimentation

Posted Apr 11, 2010 8:48 UTC (Sun) by njs (subscriber, #40338) [Link]

Sadly, ion3 doesn't exactly count as part of the "open source community".