| |||||||||||||
A proposed Subversion vision and roadmapA proposed Subversion vision and roadmapPosted Apr 3, 2010 15:53 UTC (Sat) by lmb (subscriber, #39048)Parent article: A proposed Subversion vision and roadmap
"What's more, huge classes of users remain categorically opposed to the very
tenets on which the DVCS systems are based. They need centralization. They need control. They need meaningful path-based authorization. They need simplicity. In short, they desperately need Subversion."
Interesting requirement analysis - but, I think, the wrong conclusion. There is nothing preventing a "centralized" DVCS setup (indeed, most DVCS project have the concept of a "primary" repository), implementing path-based authorization, or using just a "simple" subset of its features.
The opposition comes from fear of change or misunderstandings (namely, the perception that all the DVCS features need to be used or understood in all scenarios), and from clinging to outdated past; it's like the initial resistance to SVN adoption when CVS/SCCS were still around.
(Log in to post comments)
path-based authorization? Posted Apr 3, 2010 17:08 UTC (Sat) by johill (subscriber, #25196) [Link]
Because of course everything needs to be in a single repository.
???
path-based authorization? Posted Apr 3, 2010 18:21 UTC (Sat) by rillian (subscriber, #11344) [Link]
Subversion's lack of support for merging between separate repositories means it's much better to have everything in a single, organization-wide repository, even if that means you need things like path-based authentication to enforce project boundaries. And it's best to do this preemptively because there's no good way to import project history when you discover you need to merge differences later.
At least, that's been my experience. Subversion really does encourage centralization.
A proposed Subversion vision and roadmap Posted Apr 3, 2010 17:31 UTC (Sat) by marcH (subscriber, #57642) [Link]
> The opposition comes from fear of change or misunderstandings (namely, the perception that all the DVCS features need to be used or understood in all scenarios)
I think the point you are missing is the following: some workplaces want to make sure developers cannot be creative and cannot even think of any workflow different from the official one.
Workflow Posted Apr 4, 2010 7:11 UTC (Sun) by smurf (subscriber, #17840) [Link]
As long as people can email (or carry USB sticks with) files to each other, the only technical result of auch restriction-from-above is that the inofficial workflow won't be documented in the VCS.
Whhy anybody would want its mmany social ramifications, all of which detrimental, is beyond me, but then there's a reason why I'm not a manager. :-P
Workflow Posted Apr 6, 2010 19:36 UTC (Tue) by marcH (subscriber, #57642) [Link]
So you are using a centralized VC. You require some piece code from your collegue and he is not keen on committing it yet. He sends you an early version as a patch (by email or USB or else). You work on top of that. Great, but good luck committing anything. Meanwhile your collegue updates his patch. How do you merge his new stuff since he can only give his whole work from scratch? Etc.
Soon enough you give up this strange and doomed experiment of using a centralized tool in a decentralized fashion and you create a branch for the two of you.
|
|||||||||||||