| |||||||||||||
Subversion considered obsoleteSubversion considered obsoletePosted Apr 5, 2010 17:21 UTC (Mon) by iabervon (subscriber, #722)In reply to: Subversion considered obsolete by Msemack Parent article: A proposed Subversion vision and roadmap
You can, in theory do everything with a DVCS that you can with a centralized system; you just can't do everything with the current crop of DVCSes. There's no fundamental reason a DVCS can't have an integrated lock manager, where you can negotiate with some server in advance to prevent anyone but you from changing a particular branch to have a different file at a particular path than you have there, and have the repository configured to advise users to get this kind of lock on certain files before working on them. They can, of course, ignore that, and a DVCS means they are able to track their changes locally while still not being able to get their work into the official location, but that's not really different from someone using "Save As..." to avoid getting the lock. (And having an API for getting the versions for a merge in process means that, in theory, your CAD program could have support for performing the merge, and people who really want to work while someone else has the lock could potentially get started early and do more work total but spend less time waiting if they merged.)
Also, a DVCS could, in theory, know where to get all the big uninteresting files instead of actually storing them on the client. That is, for files that aren't useful to compare aside from identity, it would be perfectly reasonable for the DVCS to store on the client "hash xyz is available at (location)", and only actually get the content when needed. For that matter, a DVCS could store the content of large binary files in bittorrent (or a site-internal equivalent) and beat a centralized distribution point.
So far, we haven't seen any DVCSes that do either of these things, but there's not reason they couldn't, aside from the fact that there aren't developers who want to work on those particular problems. That is, version control programs are written in environments with merging and files that compress well against each other and other versions of the same file; this means that "eating your own dogfood" isn't sufficient to motivate developers of version controls systems to fix these problems, and centralized systems, by and large, tend to just happen to work for these cases by default or with very little design effort.
(Log in to post comments)
Subversion considered obsolete Posted Apr 5, 2010 17:46 UTC (Mon) by Msemack (guest, #65001) [Link]
A central server to do locking? How about that!
Subversion considered obsolete Posted Apr 5, 2010 18:01 UTC (Mon) by iabervon (subscriber, #722) [Link]
In all version control environments, there's a central location that is where different participants find each other. In distributed systems, this is just a social convention (and subject to change), and not a necessary part of the architecture, and not critical to all operations. In any case, every branch, whether it is the main branch on the official server that the release will be made from or just the representation of the present state on a developer's workstation, could have locks available; it's just that nobody would try getting a lock somewhere other than the interesting branch, which is the de facto central location.
Subversion considered obsolete Posted Apr 6, 2010 19:07 UTC (Tue) by vonbrand (subscriber, #4458) [Link] Why all this locking nonsense? You have complete control over your clone of the central repo (as a bonus, nobody sees any dumb experiments you try). Use something like gitolite to provide finer-grained access to a shared repo. And have a real person as a gatekeeper for changes. Call them QA or something.
Subversion considered obsolete Posted Apr 6, 2010 20:01 UTC (Tue) by iabervon (subscriber, #722) [Link]
The use case for locking is when your development effort consists of files that can't be merged effectively (CAD is a common example) that various different people work on at different times. Locking is used as a machine-readable alternative to telling everybody in the company "I'm working on the fenders right now, don't work on them until I'm done" and "I'm done with the fenders" and trying to get everyone to notice when people have made these requests.
It's only relevant to projects where merge conflicts can't be resolved (and if you get a merge conflict, someone's work has to be thrown away and redone from scratch), where you want the person whose work would be wasted to do something else or take the afternoon off instead of wasting their time, but these are important cases in a number of industries that aren't software development.
Subversion considered obsolete Posted Apr 7, 2010 1:10 UTC (Wed) by vonbrand (subscriber, #4458) [Link] The git way to handle this is to have everybody work in their own area (no "I step on your toes" possible), and merge the finished products when the developer say it is done. As everybody can also freely take versions from anybody, this doesn't restrict work based on not-yet-accepted changes in any way (sanctioning a change as official is an administrative decision, as it should be, not one forced by the tool).
Subversion considered obsolete Posted Apr 7, 2010 2:13 UTC (Wed) by iabervon (subscriber, #722) [Link]
But the thing is that there is no point in working on a part when someone else is working on it, because merging the results is harder than just starting over. I've dealt with situations where every time a hardware schematic changed, the engineer had to spend half a day rerouting the traces so they would fit, and if two people changed the schematic at the same time and rerouted the traces, neither of their layouts would be helpful in routing the merged schematics. Your version control system can't solve problems that your development environment can't solve, and the solution is to have locks such that the second engineer can work on something else instead of spending a day on work that doesn't contribute to the final result.
Subversion considered obsolete Posted Apr 7, 2010 20:21 UTC (Wed) by vonbrand (subscriber, #4458) [Link] OK, but this is a problem that no VCS can solve (because there is no reasonable way to merge separate modifications). Locking doesn't help either, in any case this requires administrative (workflow) coordination between people.
Subversion considered obsolete Posted Apr 7, 2010 20:32 UTC (Wed) by foom (subscriber, #14868) [Link]
Maybe you don't understand what is meant by locking?
The advisory locking in SVN *is the implementation of* the administrative (workflow) coordination
|
|||||||||||||