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!

The Future of Subversion

kdawson posted more than 6 years ago | from the had-a-good-run dept.

Software 173

sciurus0 writes "As the open source version control system Subversion nears its 1.5 release, one of its developers asks, what is the project's future? On the one hand, the number of public Subversion DAV servers is still growing quadratically. On the other hand, open source developers are increasingly switching to distributed version control systems like Git and Mercurial. Is there still a need for centralized version control in some environments, or is Linus Torvalds right that all who use it are 'ugly and stupid'?" The comments on the blog post have high S/N.

cancel ×

173 comments

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

S/N Ratio (4, Funny)

Anonymous Coward | more than 6 years ago | (#23351224)

The comments on the blog post have high S/N.
And posting it here is really going to help!

Re:S/N Ratio (0)

Anonymous Coward | more than 6 years ago | (#23355298)

Do you think so?

Well *I'm* ugly and stupid... (5, Insightful)

Wulfstan (180404) | more than 6 years ago | (#23351268)

I run the IT systems for my small software company and frankly Subversion is a great tool for the job. I don't *want* a distributed VC system because I don't want the hassle of trying to ensure that everyone's modifications to the code tree are backed up correctly and stored safely somewhere. I want it in a central spot I can back up and manage without my employees having to worry about it.

Basically Subversion is not suited for development with a diverse population of loosely connected individuals, each with their own private branches. Frankly, for corporate work, I don't understand why you would want the backup and integrity hassles of a distributed version control system. But maybe that's because I'm ugly and stupid :-)

Re:Well *I'm* ugly and stupid... (3, Insightful)

mweather (1089505) | more than 6 years ago | (#23351426)

I run the IT systems for my small software company and frankly Subversion is a great tool for the job. I don't *want* a distributed VC system because I don't want the hassle of trying to ensure that everyone's modifications to the code tree are backed up correctly and stored safely somewhere. I want it in a central spot I can back up and manage without my employees having to worry about it.
You can do that with distributed version control, too and still have the flexibility for alternative work flows.

Re:Well *I'm* ugly and stupid... (3, Interesting)

Wulfstan (180404) | more than 6 years ago | (#23351530)

Errr. I don't see how without jumping through a lot of hoops.

If I have n users in my software team and they each have a local repository copy and "commits" that they make are made to that local repository then it basically requires me to backup everyone's PC in order to ensure that work is not lost. I don't back up PCs, we have a clear rule that if you want something to be safe it goes on the server.

Now, sure, I can see that with some effort and mucking about you can ensure that everyone's local repository copies are backed up. But this is a whole lot of hassle and I fail to see why you would bother - other than if you have a particular religious requirement to use a DVCS ;-)

Re:Well *I'm* ugly and stupid... (1, Informative)

Anonymous Coward | more than 6 years ago | (#23351836)

There's no reason you can't have a central "official" repository that everyone "pushes" their changes to. In fact, I bet most "corporate" users of DVCS do exactly this. You also get all the other benefits of DVCS that Subversion doesn't do or doesn't do well.

You shouldn't knock things you obviously don't know much about.

Re:Well *I'm* ugly and stupid... (1)

Mongoose Disciple (722373) | more than 6 years ago | (#23351958)

You also get all the other benefits of DVCS that Subversion doesn't do or doesn't do well.

Examples? Specifically, I'm wondering what advantages a DVCS can offer in a situation where what you would choose is very close to or exactly like the centralized model that something like Subversion forces on you -- and similarly, what the trade-offs are.

I know that's not the situation for most Open Source projects, but I think it is the case for a lot of businesses that are currently running Subversion, or are looking at Subversion to replace whatever older and crappier VCS they have. Probably I'll have to make that kind of call at least once in the next few years and it would be nice to have a better handle on the pros and cons.

Re:Well *I'm* ugly and stupid... (2, Interesting)

burris (122191) | more than 6 years ago | (#23352112)

One of the best things is you can checkin changes, roll back to previous versions, branch, merge, etc... all on your local repository while you're on the plane or beach where there is no network access. With Subversion you can't do that. So if you have this crazy idea but don't have network access, you either have to make changes to your current work area and risk screwing stuff up and possibly losing any changes you already have in that work area (which may not be as crazy and speculative) or you might just forgo trying out your crazy ideas because you can't take a branch or commit your changes. The same goes for when you do have network access. The DVCS systems are much faster at branching and the merging is much better IME. Most Subversion/CVS users avoid making many branches because keeping them in sync is a PITA.

Most CVCS users don't realize how incredibly useful taking branches and merging them at the drop of a hat is because they have studiously avoided it except where absolutely necessary.

Re:Well *I'm* ugly and stupid... (1)

joggle (594025) | more than 6 years ago | (#23352238)

Thanks, I hadn't thought of that. So which DVCS would you recommend?

Re:Well *I'm* ugly and stupid... (5, Informative)

burris (122191) | more than 6 years ago | (#23352490)

I have worked with almost all of them. Some of them for extended periods of time with developers I sat next to in the office who committed to a central repository but also with distributed teams (distributed teams usually push changes frequently to a shared "central" repo, btw.) That includes Codeville, Git, Monotone, Darcs, and Mercurial. Really, they are all essentially the same and the differences are mostly in implementation and flexibility, especially WRT merge algorithms.

A few months ago I switched to git. Git seems like the winner - it's fast, modular, and many people are hacking on it and have written many cool tools (most of which are "built-in" git "commands.") However, its Windows support lags behind the other front-runner Mercurial. Darcs is mostly used by Haskell hackers, Monotone never seemed to really take off, and Codeville has died on the vine.

The good thing is you can switch because there are migration tools for almost every one and the histories tend to be isomorphic.

Re:Well *I'm* ugly and stupid... (1)

joggle (594025) | more than 6 years ago | (#23354896)

Thanks for the info. We're still using CVS here (much to my annoyance) but are planning to switch to something new soon. I'll give Git a try.

Note to mods: I don't think the sibling post by gbjbaanb was a troll. A disagreement does not a troll make. His post was on-topic and not insulting so I really can't see why somebody would mod it as 'troll'.

Re:Well *I'm* ugly and stupid... (1, Insightful)

gbjbaanb (229885) | more than 6 years ago | (#23352450)

One of the best things is you can checkin changes, roll back to previous versions, branch, merge, etc... all on your local repository while you're on the plane or beach where there is no network access

no, that's the WORST thing about it in a corporate environment. See, if I've paid you $5000 a month to write software, I don't mind it written on a laptop on the beach as long as you check it into the central repository. I seriously do mind if you write it on your laptop on the beach, check it in to your local repository and then get your laptop stolen (or covered in margeritas). This is such a deal-breaker that I would say 'no beach coding' to all developers and make them sit in cubicles instead. Now if they could check code into the central, secure, backed-up repository then I'm fine with whereever they want to code.

Now branching... that's another story and is possibly why this article should be talking about the differences between MS Team Foundation System and Clearcase.

Re:Well *I'm* ugly and stupid... (0)

Anonymous Coward | more than 6 years ago | (#23352786)

See, if I've paid you $5000 a month to write software, I don't mind it written on a laptop on the beach as long as you check it into the central repository. I seriously do mind if you write it on your laptop on the beach, check it in to your local repository and then get your laptop stolen (or covered in margeritas). This is such a deal-breaker that I would say 'no beach coding' to all developers and make them sit in cubicles instead. Now if they could check code into the central, secure, backed-up repository then I'm fine with wherever they want to code.


This confuses me. Why can't you just have a corporate server with a repository that is the "official" repository (i.e., a centralized repository), but individuals can checkout a version, then work on it at the beach or wherever--including "committing" at the beach on their local laptop. However, until they push that change back to the central server, it is not considered completed work? This doesn't seem to be any different than having a true centralized svn repository, checking out code, working at the beach, then committing it later.


Even if you have a centralized svn repository, someone can checkout, make changes at the beach, then spill a margarita on the laptop and lose that work anyway.

Re:Well *I'm* ugly and stupid... (0)

Anonymous Coward | more than 6 years ago | (#23355372)

No, you're not paying me $5,000 a month to write software because I won't work for that little. Especially because you're obviously a jerk.

Re:Well *I'm* ugly and stupid... (0)

Anonymous Coward | more than 6 years ago | (#23354960)

There's no reason that you couldn't do this same thing with a CVCS, and I know that at some of the Subversion conferences they have even talked about adding support for the offline access to a local copy of the repository.

Re:Well *I'm* ugly and stupid... (0, Flamebait)

KDan (90353) | more than 6 years ago | (#23352136)

In short, it makes creating branches and rebasing those branches so easily that you get a whole new verb to your version-control vocabulary. This allows a much more natural development workflow.

The only downside, I would say, to something like git, is that if your head is empty it'll just confuse you. At the moment, Git is too flexible and powerful for bad developers. I wouldn't recommend git in your outsourcing sweat-shop in Pakistan, for instance.

Daniel

Re:Well *I'm* ugly and stupid... (1)

mweather (1089505) | more than 6 years ago | (#23353538)

My Pakistani coding center is NOT a sweatshop. Heat might damage the equipment.

Re:Well *I'm* ugly and stupid... (2, Interesting)

corbettw (214229) | more than 6 years ago | (#23351970)

There's no reason you can't have a central "official" repository that everyone "pushes" their changes to.
How is that substantially different from what the OP described?

In any event, anyone advocates distributed version control has never been responsible for protecting the work of hundreds of developers working in multiple timezones/continents. Enterprises cannot afford the cost in time and money to back up every single workstation; developers have to be given a way to sync their work, at least once a day, with a central repository that can protected against data loss.

Re:Well *I'm* ugly and stupid... (1, Informative)

Anonymous Coward | more than 6 years ago | (#23352460)

In distributed implementations in the past that I've been responsible for, the tool (in my case BitKeeper) allows a "push clone" where a developer can create a clone of their local workspace onto a remote system, in this case a common server.

That server was regularly backed up (daily deltas) with weekly off-site tape rotation.

The worst-case loss in the event of a total failure of a single computer is one developer's local changeset(s), but that's the exact same risk when working with a centralized system as well. A developer's uncommitted work can always be lost if precautions aren't taken.

Re:Well *I'm* ugly and stupid... (1)

Wulfstan (180404) | more than 6 years ago | (#23352678)

The worst-case loss in the event of a total failure of a single computer is one developer's local changeset(s), but that's the exact same risk when working with a centralized system as well. A developer's uncommitted work can always be lost if precautions aren't taken.
That's slightly disingenuous - in a DVCS you are more likely to have local changesets than you are to have uncommitted work in a CVCS. So saying that it's the exact same risk I think is a bit unfair.

Re:Well *I'm* ugly and stupid... (2, Insightful)

Wulfstan (180404) | more than 6 years ago | (#23352024)

Yes, but the point is that it encourages and allows behaviour that is not desirable in a corporate development environment - local checkins. You CAN push your changes to it but equally you CAN just check stuff in locally. In some contexts this is great - but I think in corporate environments it promotes risky behaviour.

Look - it's a tool - you can use it responsibly or use it irresponsibly - with the right set of rules and processes I'm sure it can be made to work. Local checkins are what really get my goat ;-)

Re:Well *I'm* ugly and stupid... (1)

plague3106 (71849) | more than 6 years ago | (#23352444)

By local checkins, do you mean the idea of shelving? I don't think you necessarly need a distributed system to have that feature. A centralized repositry can support such features as well. Or are local checkins something else I don't know about?

Re:Well *I'm* ugly and stupid... (2, Interesting)

Wulfstan (180404) | more than 6 years ago | (#23352600)

I mean the idea of being able to commit changes to your local copy of the repository (whatever that is called in your DVCS of choice) without having them pushed up automatically to a "safe" central location. We encourage the use of private branches in SVN instead. Yes, merging in SVN stinks, but svnmerge.py at least makes it tolerable.

In my environment servers are backed up and PCs are not, which is why local repository copies I think are risky.

I appreciate that you could add this sort of feature to a centralized repository but I see that as one of the key differentiators between DVCS and CVCS. If it was a feature in a CVCS I'd be pretty negative about people making use of it without particularly good reasons...

Re:Well *I'm* ugly and stupid... (2, Informative)

plague3106 (71849) | more than 6 years ago | (#23353146)

Well, it sounds like the concept of shelving; a kind of partial commit that only you can see, and if you like, can later make public. I don't believe you need distributed SC for that; there's nothing inherient that requires a local server running. I believe MS' Team Foundation Server already supports this. http://msdn.microsoft.com/en-us/library/ms181283(VS.80).aspx [microsoft.com]

Maybe it's not the same thing though. To me, the key difference would be running your own private SC server locally to handle the feature vs. not having any local server but the central server knows to "hide" it. At least that's how I would think a distributed source control system would work.

Re:Well *I'm* ugly and stupid... (2, Interesting)

xannik (534808) | more than 6 years ago | (#23352756)

Yes, but the point is that it encourages and allows behaviour that is not desirable in a corporate development environment - local checkins. You CAN push your changes to it but equally you CAN just check stuff in locally. In some contexts this is great - but I think in corporate environments it promotes risky behaviour.
What's the difference between that and using a centralized VCS where the users are keeping copies of the code, but aren't checking in their changes?

Re:Well *I'm* ugly and stupid... (1)

taylortbb (759869) | more than 6 years ago | (#23354546)

Because sometimes you want granularity in your check-ins, or you might want to make a local branch. This way you can check things in bit by bit to your local repository and then sync it up to the main one when you're done. That way a major change doesn't come in one mammoth commit.

Re:Well *I'm* ugly and stupid... (1)

Wulfstan (180404) | more than 6 years ago | (#23355438)

There isn't any difference, you're right - but I think DCVS tools encourage disconnected behaviour whereas CCVS tools don't.

You can use any tool badly, but some tools are easier to use badly than others.

Re:Well *I'm* ugly and stupid... (5, Informative)

maxume (22995) | more than 6 years ago | (#23352286)

A DVCS can still be used to commit to a server.

The big difference is that a DVCS adds a local workspace. I can check something out from the centralized server(with a DVCS, I pull the server tree to my local tree), mess around, make a branch, see what it does, decide it was stupid and throw the whole thing away, or I can decide it was a good idea and then commit it to the centralized server(by pushing my tree up to the central tree). The only real difference is that a check out is called a pull and a commit is called a push.

Separating change management from committing to the repository is not necessarily a bad thing. It may be undesirable in many situations, but it can also be handy.

Re:Well *I'm* ugly and stupid... (1)

Wulfstan (180404) | more than 6 years ago | (#23352458)

I don't think it's necessarily bad - people are bringing up valuable points about contexts in which it is useful - I worry that local checkins encourage individuals working in a disconnected fashion and thinking less like a team.

"Commit" has always had an air of safety for me which DVCS seems to compromise. But maybe I'm a Luddite as well as being ugly and stupid ;-)

Re:Well *I'm* ugly and stupid... (4, Informative)

maxume (22995) | more than 6 years ago | (#23352666)

Right, but with server only commits, people wanting to do experiments may not bother doing any version management if they don't want to hassle with creating a branch to hold the work. Cultural problems come up in both situations.

Re:Well *I'm* ugly and stupid... (0)

Anonymous Coward | more than 6 years ago | (#23354806)

And why can't you do that same thing with Subversion?

Re:Well *I'm* ugly and stupid... (3, Insightful)

peragrin (659227) | more than 6 years ago | (#23351490)

i would say it is variable. I can see the point of both.

subversion is good for small projects, or larger projects with limited number of developers.

Once you get into the hundreds and thousands of developers working on the same project though you need to think a bit differently in terms of needs of the individual developer, and the group as a whole.

Uhm... (1)

warrax_666 (144623) | more than 6 years ago | (#23351492)

Give developers a personal directory on a shared network drive. Developer repositories/branches stay there(*). Backup shared network drive. Done.

(*) Don't know about any other systems than Bazaar, but I expect they have similar functionality: Bazaar has "checkouts" which enable you to have a local branch (i.e. on C:/Projects/Whatever) while also auto-committing to the "source" (i.e. the shared directory/drive) when you do a local commit.

Re:Well *I'm* ugly and stupid... (5, Insightful)

EricR86 (1144023) | more than 6 years ago | (#23351550)

Frankly, for corporate work, I don't understand why you would want the backup and integrity hassles of a distributed version control system.

Correct me if I'm wrong, but isn't this the major selling point of distributed revision control? The idea being that since it is a distributed repository, everyone has a "backup" of someone else's repository (depending where they got their code from). No distributed copy is necessarily considered more important than another. However in a corporate environment I would imagine it works out quite well since there's an inherent hierarchy. Those "higher up" can pull changes from those "below". Those "higher" repositories you could (and probably should) backup.

As far as integrity goes I think one of the main goals of both Mecurial and Git was to protecting against corruption (using a SHA1 hash). You're much more likely to get corruption through CVS and SVN, which is awful considering it's in a central location.

Re:Well *I'm* ugly and stupid... (5, Insightful)

Wulfstan (180404) | more than 6 years ago | (#23351728)

I'm using the terms backup and integrity in slightly different ways than you are.

By backup - I mean a tape or location where I know I can look to find the "good" copy that contains the official tree of code that represents what is going into my product. What you are describing is copies of repositories sitting in various locations that isn't really the same as a backup. It's also a bit upside-down - I don't want to be "pulling" fixes from engineers, I want engineers "pushing" fixes into a known-good integration environment.

By integrity - I mean ensuring that you have all of the fixes you want to have from everyone who should be making changes on a project. NOT file corruption.

Re:Well *I'm* ugly and stupid... (5, Insightful)

EricR86 (1144023) | more than 6 years ago | (#23352072)

...a tape or location where I know I can look to find the "good" copy that contains the official tree of code that represents what is going into my product.

In a distributed environment usually there's someone's (or a group's) repository that's considered more important than others. In a software setting this could be a Lead Engineer's/QA/Certification's repository. Depending on what your definition of the "good" repository is, you would take the copy from the right place. It opens up in terms of flexibility what code you actually want to get to work with. The upcoming released version of your software from QA, the next-generation stuff that developers are working on, or maybe a new feature that you here so-and-so is working on...

I don't want to be "pulling" fixes from engineers, I want engineers "pushing" fixes into a known-good integration environment.

But you have someone who needs to approve a change to a central repository that everyone shares. Right? That person would probably want to examine those changes before they're committed. The only difference between distributed and centralized, in this case, is that it's a required step. Everyone is responsible for their own repository.

By integrity - I mean ensuring that you have all of the fixes you want to have from everyone who should be making changes on a project
Again, in a centralized system, someone has to have the responsibility that all "fixes" have been made which isn't much different from a distributed model. And technically anyone is free to make changes to a project locally on their own machine. They just have to notify the "higher" person saying "Hey I've got a fix for so-and-so", and in a controlled manner they can decide whether or not to accept the changes into their own repository.

I'm no expert on distributed revision control, so anyone please feel free to correct me.

Re:Well *I'm* ugly and stupid... (1)

Workaphobia (931620) | more than 6 years ago | (#23353034)

But since patches are decentralized and often independent of one another (whereas in SVN they're sequential), you have to take extra care to make sure everyone has a complete copy of the full, up to date project, and not just a widely distributed older variation.

Distributed VCS can be used like this (3, Insightful)

this great guy (922511) | more than 6 years ago | (#23351792)

You do realize that a distributed VCS can perfectly be used like a centralized VCS, don't you ? Declare any repository as the "central" one and decide that everybody should push/pull to/from it. That's their power: discributed VCS don't force you into a specific workflow, you choose how you want to use them.

Re:Distributed VCS can be used like this (2, Insightful)

Wulfstan (180404) | more than 6 years ago | (#23351904)

What worries me is that it encourages behaviour which leaves valuable changes sitting on a disk which may not be backed up. I see changes being made to a codebase like valuable little bits of gold which need to be kept somewhere nice and safe, which is not on individual machines but on the server (RAID, redundant power, UPS, etc)

Yes, if you are disciplined about how you use it then I'm sure you can use it like any centralised VC. It is a tool - it is not evil - it just encourages what I see as risky behaviour in my particular environment. But I can fully understand that in other contexts it may be useful.

Re:Distributed VCS can be used like this (2, Insightful)

this great guy (922511) | more than 6 years ago | (#23352186)

What worries me is that it encourages behaviour which leaves valuable changes sitting on a disk which may not be backed up.

Huh ? If you don't push to the main repo, nobody sees your commits. Don't you think this is sufficient to remember DVCS users they need to push regularly ?

Re:Distributed VCS can be used like this (2, Informative)

Wulfstan (180404) | more than 6 years ago | (#23352378)

"Valuable changes" doesn't only mean changes which are destined for HEAD or the equivalent. "Valuable changes" in my opinion is anything and everything that you are doing on a codebase.

I take your point - if you are responsible in how you use DVCS then I can see that it can be made to work. But in my environment I want all of the changes being made (however offensive or broken) to be centrally auditable and not stashed away in some private repository.

Re:Distributed VCS can be used like this (5, Insightful)

this great guy (922511) | more than 6 years ago | (#23353108)

How do you force your cvs/svn users to commit ? You can't, you expect them to be responsible and do it. This isn't much different from a DVCS.

What if a user wants his work to be backed up but doesn't want to commit because his changes are not ready to be published ? A centralized VCS forces them to commit with the side-effect of making their unfinished work immediately visible in the central repo, while a DVCS lets them commit to a private repo that you can back up independently.

Your backup requirements can be solved 2 different ways:

  • 1. With any VCS (centralized or distributed), put the users' working directories on private NFS/Samba shares. This way everybody's work, committed or not, is on the file server which can be backed up.
  • 2. Use a DVCS. The users' private repos and working directories can remain on fast local storage on their workstations. A file server contains the main repo as well as private spaces that can be used by the users to periodically push to private repos, so they can be backed up without interfering with the main repo.

Besides, in this debate, you are completely ignoring the other major advantages of DVCS over centralized ones: scalability, no single point of failure, possibility to work offline and have full access to all of the features of your VCS, usually faster than centralized VCS, low-cost branching/merging, etc.

Re:Distributed VCS can be used like this (1)

marcosdumay (620877) | more than 6 years ago | (#23354264)

Besides, in this debate, you are completely ignoring the other major advantages of DVCS over centralized ones: scalability, no single point of failure, possibility to work offline and have full access to all of the features of your VCS, usually faster than centralized VCS, low-cost branching/merging, etc.

Except that at a corporate environment only low-cost branching merging holds.

Re:Distributed VCS can be used like this (1)

Uncle Focker (1277658) | more than 6 years ago | (#23354362)

But in my environment I want all of the changes being made (however offensive or broken) to be centrally auditable and not stashed away in some private repository.
But that's a risk of any VCS. Exactly how is that any less of a concern just because you have a centralized server? I've seen that exact situation happen innumerable times using a CVCS. It seems more like you're just afraid of something you don't understand.

Re:Distributed VCS can be used like this (1)

Wulfstan (180404) | more than 6 years ago | (#23355598)

It's less of a concern because the pattern of behaviour that is encouraged. DVCS encourages independent working in an "uncontrolled" independent repository whereas CCVS encourages working interdependently in a centralized repository. So it's less of a concern because unless you really go out of your way to be a psycho (weeks without committing a change) you will naturally commit your changes for fear of losing your version history.

It's always possible to have some psycho who does an svn export and makes his own little repository somewhere away from the rest of the team. Yes, I've seen it done too. But tools naturally support certain ways of working and DVCS I think encourages behavior which would not be desirable in corporate software development.

It's not that I don't understand how it works, I do - and I appreciate that you can use any tool irresponsibly - but I'm not convinced that for the type of software development that most companies do DVCS makes sense.

Re:Distributed VCS can be used like this (3, Informative)

Chemisor (97276) | more than 6 years ago | (#23353870)

> What worries me is that it encourages behaviour which leaves valuable changes sitting
> on a disk which may not be backed up. I see changes being made to a codebase like valuable
> little bits of gold which need to be kept somewhere nice and safe

As a developer, I'll tell you that not all changes are "little bits of gold". Sometimes I just want to try something out, and end up with little bits of crap. The way to think about local changes is the same way you think about non-committed changes to your Subversion repository. In Subversion, I will have plenty of changes sitting on my disk, they just won't be committed until I am satisfied with them. In git, I can commit as many times as I like to my local repository and push only the final version to the central branch. This way I can checkpoint my code with intermediate commits. This is extremely valuable, since those checkpoints might not even work at all, and I would never want them to break the main build, but I can still break up my task into little subtasks and redo or revise each one of them in turn. These subtasks are not backed up in your scenario either, and are much harder to manager there.

Re:Well *I'm* ugly and stupid... (0)

Anonymous Coward | more than 6 years ago | (#23351832)

this can of irony just makes my day:

"Well *I'm* ugly and stupid... (Score:5, Insightful)"

Re:Well *I'm* ugly and stupid... (1)

JosefWells (17775) | more than 6 years ago | (#23352672)

I don't *want* a distributed VC system because I don't want the hassle of trying to ensure that everyone's modifications to the code tree are backed up correctly and stored safely somewhere. I want it in a central spot I can back up and manage without my employees having to worry about it.
With svn/cvs, any uncommited edits in a developers personal checkout are not backed up! You would need to back up their machines or work areas to achieve this.

With mercurual/git, users can commit unfinished code without affecting the release branch. You can wrap those commits, so they always get pushed to some server which then CAN backup that unfinished work in a central location.

Distributed version control adds this feature which central version control via svn/cvs specifically lacks.

Re:Well *I'm* ugly and stupid... (3, Interesting)

ajlitt (19055) | more than 6 years ago | (#23353274)

Most CVCS users do work on development or experimental branches for exactly that reason. That way you can follow the 'commit often' rule. You really should only be doing merges to release branches or the trunk.

Re:Well *I'm* ugly and stupid... (1)

Smenj (648240) | more than 6 years ago | (#23352714)

You clearly do not understand distributed revision control.

Fostering decentralization in no way prevents you from enforcing a centralized workflow, if that's what you choose to do. Rather it provides you with capabilities that simply are not possible in a centralized system. You do not have to take advantage of them if you don't want to.

Of course, with a decentralized system everyone has a complete copy of the history by default, so if you lose the original or the "official" backups you're not screwed.

Of course, you are welcome to do what you like. You will simply miss out on all the advancements your competitors are taking advantage of.

Re:Well *I'm* ugly and stupid... (0)

Anonymous Coward | more than 6 years ago | (#23353408)

> Of course, with a decentralized system everyone has a complete copy of the history by default

Not in any project of reasonable size. No one checks out the entire gigantic git history of Linux, they get a current snapshot that starts history at the time of checkout.

Re:Well *I'm* ugly and stupid... (1)

greg1104 (461138) | more than 6 years ago | (#23353148)

The way you're working with Subversion right now, each developer checks out a copy where they are making private temporary modifications in order to improve the code, only to check the result in when it's done. You have no ability to see, backup, or manage those private checkouts, even though there may be substantial work going into them each day. You should consider that a large problem with using Subversion. If you're lucky, developers make branches and commit to that regularly so there's less chance of losing that work, but since branches are so painful in svn that's probably not happening for anything but major projects.

With a DVCS, you can have each developer publish their private version of the code and see what they're doing at any time. When they have a good changeset ready, they integrate that back into the master repository--updating your central spot you worry about backing up, same as you always have. But in addition to that, you have visibility into work in progress that the Subversion model only provides if people go out of their way to enable it.

Re:Well *I'm* ugly and stupid... (1)

imbaczek (690596) | more than 6 years ago | (#23354636)

I run the IT systems for my small software company and frankly Subversion is a great tool for the job. I don't *want* a distributed VC system because I don't want the hassle of trying to ensure that everyone's modifications to the code tree are backed up correctly and stored safely somewhere. I want it in a central spot I can back up and manage without my employees having to worry about it.
Clearly you have no idea how DVCSes work. Every employee has his own backup and you still can tell them (or force them) to push changes to a blessed server (which can be called central, but this isn't a _technical_ thing anymore), copy of which you can then safely stash away.

There are two things a DVCS can't do that a CVCS can:
1. Delete something from global history (just can't be done, because everyone has his own backup)
2. Partial checkouts (if you've got a monolithic repository instead of per-project.)
Everything else works perfectly fine and/or better.

Dog penis (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23351320)

You are now thinking about the shape, color, and texture of a dog's penis.

Re:Dog penis (-1, Offtopic)

Uncle Focker (1277658) | more than 6 years ago | (#23351448)

It's true! It's really true!

Re:Dog penis (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23352396)

Actually, I'm thinking about the time I came home early from a linux convention (total sausage fest) and found my girlfriend having sex with our dog. I did what anyone would do in that situation -- dropped trou and started jacking off. She called me a pervert.

It /did/ have a good S/N ratio (-1, Offtopic)

Nimey (114278) | more than 6 years ago | (#23351322)

Until the usual suspects post tired jokes or stupid questions.

Well done.

SVN Sticking around? (2, Funny)

TofuMatt (1105351) | more than 6 years ago | (#23351454)

Git out of here.

Git vs Subversion (4, Informative)

KiloByte (825081) | more than 6 years ago | (#23351596)

While Git obviously has its strong sides, often quite overwhelming, there are cases when it sucks compared to SVN:
1. timestamps. Subversion doesn't do that by default, but it has good enough metadata support than timestamps can be hacked in easily. For Git, metastore is nearly worthless. If you store a program source, you risk just skewed builds -- for other types of data, lack of timestamps is often a deal breaker.
2. move tracking: trying to move a directory branch from one dir to another means you lose history. Rename tracking works only sometimes, often it will take a random file from somewhere else, etc.
3. large files. Take a 100MB binary file into SVN, change one byte, commit. Change one byte again. And again. Git will waste the freaking 100MB for every single commit.
4. partial checkouts. If there's a 5GB repository, you'll often want to check out just a single dir. With Git, there is no such option.
5. ease of use. I see that ordinary users, web monkeys and so on can learn SVN easily; with Git, even I had some troubles initially.

On the other hand, SVN used to have no merge tracking (I wonder what that "limited merge tracking" in 1.5 means...) which for distributed development of program sources is worse than points 1..5 together.

Re:Git vs Subversion (0)

Anonymous Coward | more than 6 years ago | (#23352584)

Regarding #4, If you're only checking out a single directory and allowed to make a commit, how did you build/test your 5GB project?

If that directory was an independent piece, it should be in a separate repository since it's logically independent. If that directory is part of a larger whole, you shouldn't be allowed to work with just that one piece. (IMO)

Re:Git vs Subversion (4, Insightful)

KiloByte (825081) | more than 6 years ago | (#23352774)

Regarding #4, If you're only checking out a single directory and allowed to make a commit, how did you build/test your 5GB project?
Note that I specifically mentioned "for things other than program sources". Most other pieces of software does not require builds, and neither it is monolithic.
To commit a change to the Linux kernel, you do need to build the whole thing. That's a monolothic thing.
To commit a change to a webpage, a graphical project, a set of biochem data, you don't need that. Do you need to check out the countless megs of Wesnoth to update your changes to a campaign? That's a modular thing.

If that directory was an independent piece, it should be in a separate repository since it's logically independent. If that directory is part of a larger whole, you shouldn't be allowed to work with just that one piece. (IMO)
If I want to modify a 5GB webpage, why would I want to checkout unrelated pieces? And having every subpage in a separate repository would be counterproductive.

Re:Git vs Subversion (2, Insightful)

0xABADC0DA (867955) | more than 6 years ago | (#23352780)

As a programmer, what pisses me off most about subversion is... well just check out their codebase and look around a bit. Yeah, it works and it does 90% of what people want it to, but the code is a giant piece of shit. That svn has been developed as a total hack job and they seemingly have spent no effort over time trying to clean it up, as a programmer, offends me. I don't know how anybody can have confidence in svn when they can't even do simple changes to it.

They've been working for years to do simple things like just updating their folder structure so it doesn't leave ".svn" folders everywhere. Or just providing an option to not store a second copy of your 2 gig repository just so you can do restore to Head (and that's all) without asking the svn server which is probably over in the closet on the gigabit ethernet anyway. They can't do this with their current code... it's so bad that they are trying to scrap the local store code entirely.

... and then there are the even simpler things like why tf can't I say "svn mv *.[ch] newfolder/" or any of the other commands that you have to use shell scripting to accomplish? That kind of thing should be simple. There are a lot of these kinds of problems in svn that never gets fixed (despite having a guy at google that is apparently paid to hack on svn).

Re:Git vs Subversion (3, Interesting)

Chemisor (97276) | more than 6 years ago | (#23354006)

> 1. timestamps.

I don't see what you are talking about. git timestamps every commit too.

> 2. move tracking: trying to move a directory branch from one dir to another means you lose history.

No you don't. If you use "git mv", like you're supposed to, history moves with you.

> 3. large files. Take a 100MB binary file into SVN, change one byte, commit.
> Change one byte again. And again. Git will waste the freaking 100MB for every single commit.

No it won't. In fact, it will use less space than SVN for that commit. Yes, git supports diffs on any kind of file, and stores them that way. It didn't always, but the current version certainly does.

> 4. partial checkouts. If there's a 5GB repository, you'll often want to check out just a single dir.

That's what git submodules are for. Furthermore, git repositories are smaller than Subversion repositories by a large factor. At least twice, and I've seen as much as a tenfold reduction. Linux 2.6 repository is only 255M in size, and that's a huge project. Anything you do will likely be much smaller.

> 5. ease of use. I see that ordinary users, web monkeys and so on can learn SVN easily;

Bullshit. The commands are almost exactly the same. I don't know what people are complaining about.

Depends on the environment (4, Insightful)

Todd Knarr (15451) | more than 6 years ago | (#23351624)

If you're in a highly-distributed development environment like Linux, where the developers are spread across multiple continents and have very little shared infrastructure and a high need to work independently of each other (either because of preference or because they don't want their work stalled by another undersea cable cut half a world away), then yes using a centralized VCS like Subversion is stupid. But if you're a developer on a project where all the developers are in a common location sharing common infrastructure, often literally within speaking distance of each other, then a decentralized VCS like Git is stupid. It's harder to maintain and, in that situation, yields none of the offsetting benefits.

Analogy: a fleet of Chevy vans vs. a freight train. The vans are far more flexible, they can travel any route needed whereas the freight train's limited to fixed tracks, and their smaller size and lower cost each let you buy a lot of them and dedicate each one to just a few deliveries in a particular area without a lot of overhead. You can fan the vans out all over the city, sending just what you need where it's needed and rerouting each one to adapt to changes without upsetting the others. But if your only delivery each day is 1000 tons of a single product from one warehouse to another 600 miles away, you're better off with that one big freight train.

Re:Depends on the environment (1)

corbettw (214229) | more than 6 years ago | (#23352076)

If you're in a highly-distributed development environment like Linux, where the developers are spread across multiple continents and have very little shared infrastructure and a high need to work independently of each other (either because of preference or because they don't want their work stalled by another undersea cable cut half a world away), then yes using a centralized VCS like Subversion is stupid.

I'd say the important differential between SVN/CVS and Git/Mercurial is the independent infrastructure. If you have thousands of developers working on a large project (or projects), spread around the world, you can still use a central repository (or maybe a collection of them) to manage source control. As long as they share a common infrastructure (eg, a WAN), it makes no difference if it's 10 guys in a start-up, or IBM working on their latest upgrade to Websphere.

Having said all that, there are tons of open source projects who use SVN for large teams of developers (Django comes to mind as one example) who have no problem using SVN for source control.

Linus has a big mouth... (5, Insightful)

gweihir (88907) | more than 6 years ago | (#23351758)

... and is primarily focussed on kernel development. Some would even say it is the only thing he knows how to do. That is fine, but it does not make him an authority on version control systems for other types of projects. Kernel development has very specific needs, not mirrored by other projects. Personally I find SVN perfectly adequate for small teams, and not only for program source code, but also for texts.

Re:Linus has a big mouth... (3, Insightful)

nuzak (959558) | more than 6 years ago | (#23352192)

Linus has a long history of flapping his jaw about kernel development topics he knows nothing about as well. To his credit, they often become topics that he didn't know about at the time that he then becomes well-educated on (SMP and /dev/poll to name a couple) but sometimes it's on things he religiously refuses to learn anything further about (microkernel architectures).

He's an excellent assembly hacker, a fast learner, and at least a majority of the time a nice guy, so most people overlook it.

Re:Linus has a big mouth... (0)

Anonymous Coward | more than 6 years ago | (#23352932)

sometimes it's on things he religiously refuses to learn anything further about (microkernel architectures).
Not exactly the best example... GLPv2/v3 comes to mind as Linus being religiously malignorant.

Microkernels like what you probably mean are just not practical due to performance and code obstacles. Sorry. "Typesafe" microkernels like Singularity or JavaOS are the way to go, but also impractical simply because they don't run existing unsafe (mostly C, C++) programs well.

Re:Linus has a big mouth... (0)

Anonymous Coward | more than 6 years ago | (#23353454)

What about OSX?

Re:Linus has a big mouth... (0)

Anonymous Coward | more than 6 years ago | (#23354224)

OS X is not microkernel at all. It has some memory protection in Mach and then the bsd 'server', but these are both linked together into the same memory space and basically the only difference is that there are some negative syscall numbers that do mach-ish things in addition to the positive syscalls that do unix-ish things. And it's actually far more complicated than say Linux.

But OS X is a good example for drivers... they aren't isolated like in a microkernel, but they are written in c++ and so most are just a few tweaks to some generic drivers.

Re:Linus has a big mouth... (1)

burris (122191) | more than 6 years ago | (#23352232)

Even when I code by myself on my own projects I greatly prefer the flexibility of git over Subversion. Why settle for "perfectly adequate" when you can have your choice of several tools that are much better?

Don't knock it till you try it (5, Insightful)

burris (122191) | more than 6 years ago | (#23352288)

Seems to me that most of the people promoting DVCS have used them and have seen the light. Once you use a DVCS on a project you don't want to go back to the bad old way of doing things.

Most of the people knocking DVCS or saying they can't see the benefits haven't actually used them on any projects. They have built up a framework in their minds of How Things Should Work, but unfortunately that model was defined by the limitations of their tools.

Re:Don't knock it till you try it (1)

Vornzog (409419) | more than 6 years ago | (#23355424)

Seems to me that most of the people promoting DVCS have used them and have seen the light. Once you use a DVCS on a project you don't want to go back to the bad old way of doing things.


Indeed. The number one complaint I hear about them is that they aren't a centralized system.

As a one man programming show and a mercurial user, I set up a centralized repository for myself. That was the clean copy - it always worked. I'd have 1-4 other copies out at any given time for whatever I was working on. It offered extreme flexibility, and at the same time, all the usual advantages of having a centralized repository. I know with mercurial (and probably most of the rest of them) that there are ways to formalize that, if it is what you need.

I hear the same things from people who have worked on larger teams with these kinds of tools.

Distributed systems let you work the way you think, rather than making you think about the way the tool works.

Spice it up a bit (1)

RockMFR (1022315) | more than 6 years ago | (#23352166)

the number of public Subversion DAV servers is still growing quadratically
No no no! If you want to describe a growth rate, you should always say "exponentially". ALWAYS.

I'm uglier and stupider (0)

Anonymous Coward | more than 6 years ago | (#23352200)

I run the IT systems for my small software company and frankly, we still use CVS.

Missing the point.. (0)

Anonymous Coward | more than 6 years ago | (#23352242)

People still seem to miss the point of something like git or BK in the corporate world. The main thing it does is to let developers organize their work before it is moved into the main central repository. Don't kid yourself, most serious devs working with something like SVN in any sort of environment with pre-checkin process will have a large bulk of work that is sitting around invisible to the SCM. Stuff that is waiting to clear the pre-checkin hurdles and be ready for commit.

The longer it takes to execute your companies QA process, the more desperately you need a distributed SCM.

git lets the developer organize this stuff very quickly, lets them share it with other people working on related stuff and records important meta-data like 'This is the exact thing I tested'.

If you have ever sat in a meeting where group A was arguing that group B needed to immediately checkin their not quite done thing because their work depends on it while group C was arguing that it wasn't done enough yet you just wasted an hour because you aren't using a distributed SCM..

If you ever had to argue with your CVS-czar that you needed a branch you just wasted an hour because you are not using a distributed SCM.

Thats ignoring the fact that merging doesn't work in SVN :P

we use SVN (5, Interesting)

Jack9 (11421) | more than 6 years ago | (#23352402)

IDE integration:
SVN is currently integrated with our IDEs (all 3), one of the main selling points in choosing a VCS.

Ease of backups:
We archive our repositories every day, IT loves being able to simply tgz the SVN directory and not have to worry about anything else, regardless of the state of any current projects (all groups use SVN).

Simplicity:
SVN/Trac training (client use, management, backend workings) takes less than 10 minutes. In another 15 minutes I can have someone setting up their own SVN repositories+Trac, without needing to pull up a single reference document, primarily because the an SVN setup methodology is trivial to memorize.

Re:we use SVN (2, Informative)

CastrTroy (595695) | more than 6 years ago | (#23354614)

On IDE Integration

I use Visual Studio with SVN at work, and while it doesn't have IDE integration (AnkSVN sucked last time I tried), which would be optimal, I find that using TortoiseSVN to be pretty adequate, if not better than IDE intergration in a lot of ways (Don't have to open the IDE to do an update on your local copy). I think the thing that makes both IDE integration and TortoiseSVN great is to be able to use a nice GUI to manage you checkins and updates. I mean, the command line works, but this is one area where having a nice GUI can really help.

Re:we use SVN (2, Insightful)

Jack9 (11421) | more than 6 years ago | (#23355420)

I personally use Tortoise but the IDEs tend to not be change-aware unless I'm using the integrated tool.

Re:we use SVN (2, Informative)

eddy (18759) | more than 6 years ago | (#23354916)

> SVN is currently integrated with our IDEs (all 3), one of the main selling points in choosing a VCS.

Where I work we all use the cmdline, so IDE integration is a complete non-issue in selecting a SCM for some teams.

> IT loves being able to simply tgz the SVN directory

Pretty sure that's not the correct way to backup a Subversion repo, unless by 'simply' you mean that you first hot-backup.py the repo and then tar it up.

Re:we use SVN (1, Informative)

Anonymous Coward | more than 6 years ago | (#23354952)

IT loves being able to simply tgz the SVN directory

If that's literally what they are doing, and they do it without shutting down access to the repository, then its being done wrong (what if someone commits during backup, for example). Hot backups are trivial in SVN, though (see repository dumping). FYI ;-)

SVN's weaknesses (3, Interesting)

Scareduck (177470) | more than 6 years ago | (#23352516)

Without saying too much about distributed version control schemes like Git (which I have never used), I have two major beefs with SVN:
  • Merges in a typical environment become effectively anonymous. Let's say you have a build manager and individual developers working on different changes in parallel. The build manager can't merge the changes without those changes taking on his identity, that is, all identifying information about the originator of the changes is lost.
  • So-called "best practice" for SVN branching means building new branches with every new release. That is, it's not recommended to build one branch and merge changes from the trunk into it as you're incrementally changing things on that branch, noooo. You have to keep polluting the repository with needless hair by making new branches every week, and sometimes, multiple ones per day.
These are just two I'm aware of that bite us in the ass on a regular basis. The first issue is supposed to be fixed in one of the near-term mods to SVN, but the fact that the second even exists tells me that the guys developing SVN don't really work in the same world as a lot of the bigger commercial development environments do.

Re:SVN's weaknesses (4, Informative)

Just Some Guy (3352) | more than 6 years ago | (#23353132)

The build manager can't merge the changes without those changes taking on his identity, that is, all identifying information about the originator of the changes is lost.

Since I'm sure you're not talking about what svn blame gives you, what do you mean exactly?

That is, it's not recommended to build one branch and merge changes from the trunk into it as you're incrementally changing things on that branch, noooo.

Umm, says who? Thanks exactly what we do. We have /trunk and /branches/devel. When one of us gets a particularly stable version of /branches/devel ready, we merge it to /trunk.

You have to keep polluting the repository with needless hair by making new branches every week, and sometimes, multiple ones per day.

Have to? No way. But since branches are basically free, why would you want to avoid them?

We use them for experimental "what-if" branches, like "I wonder what would happen if I ported our application from MySQL to SQLite". You copy "/branches/devel" to "/branches/sqlite" and hack away. If it works, merge your changes back to devel. If it bombs, just delete the branch./P

Re:SVN's weaknesses (1)

ComputerSlicer23 (516509) | more than 6 years ago | (#23354098)

Why on Earth are you generating releases that often? I've worked in a lot of shops that used SVN, and at we used the SVN revision number for our "internal" releases. Given a path and a revision number, you have a unique identifier for *EVERY* sub-directory inside of an SVN repository. Until we actually made a long term supported branch we didn't bother with human consumable names.

If you really generate multiple branches a week inside of the same repository that you intend to provide long term support for, I'm thinking you deserve the punishment you're discussing.

Branches are meant for human consumable names for long term heads to commit to. We used to drop "1.2.3.4.r56789", which meant it was on "/path/to/project/branches/project-1.2.3.4" and that it was based upon the revision 56789. Every build would contain this information. So unless I was making an *EXTERNAL* that needed long term support, this worked just fine. Plus, you can delete the "needless hair", or shut it on into it's own area. Create:

/path/to/project/daily/project-05-09-2008
/path/to/project/one-off/project-fix-name

It's not like you have to keep everything in /branches, /tags, and /trunk. The tool is a big version controlled directory structure, so think about how you would design the workflow for a directory structure that makes you happy, and do it that way.

I don't use subversion anymore, but just because you're thinking trapping yourself into thinking there's "only one way" is your problem, not that the tool won't let you construct a sane workflow.

Kirby

Re:SVN's weaknesses (1)

liquiddark (719647) | more than 6 years ago | (#23355154)

In my experience you don't WANT to have to merge into "release" branches. Merging after even a month - sometimes even a week - of development is a huge pain in the ass and doesn't net anything that having independent release branches wouldn't get you. In addition, having independent release branches means that all those internal customers who can't upgrade because of this or that interface to a critical system can still be supported via critical patches directly to their specific release. Trying to do that with a single continuous release branch would be nightmarish.

My goal regarding the future of Subversion... (3, Insightful)

lpangelrob (714473) | more than 6 years ago | (#23352518)

...getting all the other IT people in the office to use it. Even better? Getting them recognize why version control is so useful in the first place. :-D

Well if you're an MSDN developer... (2, Informative)

IgLou (732042) | more than 6 years ago | (#23352530)

If you are one of those MSDN shops where you went to subversion because VSS is weak, you can go with Team System. We were using VSS before and Team system is way better for version control plus it has defect tracking and a build agent. Also, they have caching server to aid distributed environments. Considering it's free (sort of) with your MSDN license (I think it's with their "team edition" licenses) it's tough to beat. It's tough to beat that, especially for larger shops. The only things I don't like in some ways is how it represents the branching and the source control permissions and that was comparatively minor problems. I work in Config Management/Build and so I don't know what Joe developer would like/dislike about it.

If you're not an MSDN shop then what to use is more problematic. I really liked subversion but that was years back. From what I recall for what it was it does well. The only product I was ever "wow'ed" with was Accurev. That product deals with branching like a breeze and I think they might have a defect tracking module now.

Re:Well if you're an MSDN developer... (1)

gbjbaanb (229885) | more than 6 years ago | (#23353062)

It isn't even near free.

from MS.com [microsoft.com]
Visual Studio Team System 2008 Development Edition
with MSDN Premium Subscription $5,469 $2,299

Don't forget that's $5k for the fist year, and then $2k per year renewal. It would be cheaper just to buy it, but then you'd not get the dev licences for the OS and other tools. shame really, MS used to be really good with these things but they've become too big, difficult to install, difficult to use and really expensive.

Re:Well if you're an MSDN developer... (0)

Anonymous Coward | more than 6 years ago | (#23354276)

We were using VSS before and Team system is way better for version control
You haven't exactly set the bar very high when you're comparing to VSS. RCS is better at version control than VSS.

helloooo merge tracking (5, Informative)

icknay (96963) | more than 6 years ago | (#23353102)

This probably should have been in the summary -- merge tracking is being added in 1.5, so bouncing changes from one branch to another is now easy. This is a huge feature, and something as I recall Linus specifically complained about in his talk.

http://blogs.open.collab.net/svn/2007/09/what-subversion.html [collab.net]

BTW, they did a really nice job of mapping out the use cases and whatnot before implementing the feature. I guess source control people are natural planners.
http://subversion.tigris.org/merge-tracking/requirements.html [tigris.org]

Anyway, I'm sure the world will continue to have need for both distributed and client/server source control systems, and Subversion is a nice example of the latter.

Code integration assumptions (4, Insightful)

Cyrano de Maniac (60961) | more than 6 years ago | (#23353318)

What I don't see mentioned very often, if at all, is the implicit assumption in distributed systems such as git, that a single person has ultimate integration responsibility and authority in order to form the official/mainline release. That is, given a single tree that is considered the main one from which all others ultimately derive (Linus' tree in the Linux case), there is absolutely no way for tools such as git to allow collaborative maintenance of that tree. In the end, the owner of that tree must perform all checkins to the tree, and must resolve all merge conflicts themself. This is a dual problem in that it wastes the time of a potentially talented developer (e.g. Linus) doing the mundane work of merging and integration, and the additional problem that if this mainline tree owner is not an expert in some particular area of the code, they are likely to make mistakes when resolving conflicts or performing other integration tasks.

Contrast this with a centralized source model where all developers have the ability to check in to the tree, optionally coupled with a peer review process, enforced either through convention or through mechanisms in the tools. Under this model each developer is responsible for their own integration and merging efforts, not wasting the time of a centralized authority. Not only is the central authority freed from routine tree maintenance work, but each developer can make the best and wisest decisions regarding the particular area of the codebase in which they are an expert, and not have to become involved in areas they have little experience with. Granted, for larger projects there is still a need for some management of checkin authorization, particularly to avoid conflicts during large tree merge operations and the like, but it's more of a coordination role than an authorization role.

This second model is what my employer uses, and our homegrown source control system is well-tailored to it (it actually has capabilities for more centralized control, but they are by and large unused). Perhaps this is unusual, as my experience with other employers is minimal, and mostly took the form of "copy your code into this directory once in a while" (i.e. "Source control? Why would we need that?"). However, given adequately diligent and intelligent developers, I have to say it works marvelously.

I happen to need a centralized version ... (1)

Skapare (16644) | more than 6 years ago | (#23353392)

... management system right now. One problem is, Subversion won't work because I need to have totally clean checkout trees. Subversion inserts tracking files in the checkout trees. So I guess I have to look for something else.

Re:I happen to need a centralized version ... (2, Informative)

Todd Knarr (15451) | more than 6 years ago | (#23353558)

All version-control systems do that. It's not optional: you have to have meta-information about the checked-out files available, and there's no place in the files themselves to put that information. Now, you might want to look at the distinction between a working directory (with all the tracking files present, allowing the developer to check in and out, compare with different revisions in the tree, all the normal things) and an exported tree (created using for example the CVS "export" command, contains only the source files with none of the meta-data present (which means you can't check modifications of it back in)). My normal working method is to have a working directory for actual development, then once I've got everything checked in make an export tree if I need to package the source code up for builds.

Re:I happen to need a centralized version ... (1)

Dionysus (12737) | more than 6 years ago | (#23353992)

All version-control systems do that. It's not optional: you have to have meta-information about the checked-out files available, and there's no place in the files themselves to put that information.


Sure, but there is a difference between having one tracking directory (like most DVCS like git and mercurial use), and one for each directory in your project.

Re:I happen to need a centralized version ... (1)

vrmlguy (120854) | more than 6 years ago | (#23354088)

I'm not sure that this isn't a trumped up use-case, but I wonder if it would be possible to have a parallel directory with all of the metadata in it, instead of using .svn directories. I understand that it's programatically convenient to be able to look at ./.svn/myfile wherever we are in the source tree, but things like the MacOS programs Keynote and Pages pro-actively remove .svn (and other) directories when they find them. Having a ~/.svn-meta directory that parallels the checked-out directory would be a good thing. VCS systems already know the 'base' of a project, so meta-data for $BASE/$PATH/myfile could be stored at ~/.svn-meta/$PATH/myfile, leaving a very clean checkout tree.

Re:I happen to need a centralized version ... (1)

Todd Knarr (15451) | more than 6 years ago | (#23354488)

Problem: the VCS doesn't know the base of the project. If I'm editing a file in /home/me/src/projects/utilities/ljbackup/database, exactly what portion of that path is this project's tree and which is the part the project lives under? It has to be able to figure that out with nothing more than the path available, remember, since you don't want it to store anything in the working directory indicating what the base for this directory's files is supposed to be. And it also has to accept ljbackup/database being simultaneously checked out at both /home/me/src/projects/utilities and /home/me/work, possibly at the same revision and possibly at different revisions.

CVS and SVN use meta-data under the current directory because it creates a self-contained working directory tree without any ambiguity in what the exact location of the meta-data for any given file will be.

Why do you need a working directory without meta-data present? I can't think of too many reasons, and the ones I can think of fall under "That's probably a bad idea.".

Re:I happen to need a centralized version ... (1)

Megane (129182) | more than 6 years ago | (#23354670)

All version-control systems do that.

I know for sure that Clearcase doesn't do the equivalent of putting .svn directories all over the freaking place. There's a directory of tracking files at the checkout root, and that's it. And though it's been a while since I've used CVS, I don't remember CVS spamming control files all over the place like that either.

In fact, I'd have to say that all the .svn directory spam is probably the most annoying thing to me about svn.

Re:I happen to need a centralized version ... (1)

Ritchie70 (860516) | more than 6 years ago | (#23355512)

CVS creates a subdirectory named CVS, just like SVN creates .svn.

(I'm looking at CVS on a Windows system and SVN on a Unix system, so the CVS name used under Unix or the SVN name used under Windows may be slightly different, but the directories are definitely there.)

Re:I happen to need a centralized version ... (1)

Slashdot Parent (995749) | more than 6 years ago | (#23353914)

Check out svk.

Distributed Systems Can Be Centralized (1)

CyberLife (63954) | more than 6 years ago | (#23354918)

There is nothing in the distributed systems that precludes one from using them in a centralized fashion if so desired. The term decentralized, as used in this context, simply means there is no inherent central point. It does not mean one cannot be established.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

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>