| |||||||||||||
A proposed Subversion vision and roadmapA proposed Subversion vision and roadmapPosted Apr 4, 2010 1:13 UTC (Sun) by jengelh (subscriber, #33263)In reply to: A proposed Subversion vision and roadmap by stumbles Parent article: A proposed Subversion vision and roadmap
>1. They need centralization.
Git has it. (Look what kernel.org is to us :-)
>2. They need control.
With git you have total control as a maintainer. So much control that you can reject an entire pull request just because one single file has a whitespace error. Or put more realistically: nothing goes into your repository without your consent. That's control.
>3. They need meaningful path-based authorization.
Path-based authorization is a hack for a management flaw (throwing projects together into a single repository). Suppose the filesystem maintainer only had write rights to fs/ that would most likely suck when there's an API change to be made that affects files in mm/. Doing two separate commits would introduce non-compilable commits into a bisect workflow. So people should just actually get together and actually talk about their changes and not just commit in the hope that it will be ok. That way, Git actually enforces that you get a handful of the important eyeballs that are said to make bugs so shallow (assuming a project that's not done de-facto-solo).
>4 They need simplicity.
I won't call Git outright simple, but the way it works makes it simple in the long run. Annotating (i.e. rebase -i + reorder + edit) commits something that is, at least was, last time I looked, "impossible" (read: infinitely infeasible) in SVN is one example not to miss in Git. SVN repositories seem to generally have a higher percentage of commits that (try to) fix up mistakes things post mortem again and again:
------------------------------------------------------------------------
- still not correct.
------------------------------------------------------------------------
- and again...
- fixed: M_DrawSlider did not print the correct value if the slider's minimum was not 0.
(Log in to post comments)
A proposed Subversion vision and roadmap Posted Apr 5, 2010 9:08 UTC (Mon) by oak (subscriber, #2786) [Link]
What was worse for me that when (I had to use SVN and) did "svn log" on a
directory, I got unexpected results. SVN doesn't show changes for all the files below that directory when I ask for a log. That was quite a shock.
Maybe I wasn't using the correct command/option, but SVN is supposed to be
[1] http://edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf
PS. Regarding the repository size. There was comparison of sizes a few
[2] The generic link to the this great version control blog is:
Many of the posts there are several years old, but I think still
A proposed Subversion vision and roadmap Posted Apr 5, 2010 14:10 UTC (Mon) by fw (subscriber, #26023) [Link]
Those fix-up commits aren't pretty. But I've seen Git histories which contain merges of both the rebased and non-rebased versions of development history. This is far worse. When such things happen, it can become very difficult to extract any relevant information from the DAG, severely limiting its usefulness.
A proposed Subversion vision and roadmap Posted Apr 6, 2010 23:04 UTC (Tue) by vonbrand (subscriber, #4458) [Link] You shouldn't publish rebased branches (or any branches with rewritten history that was seen before). In true Unix tradition, git provides plenty of rope to shoot your feet with...
A proposed Subversion vision and roadmap Posted Apr 6, 2010 23:14 UTC (Tue) by jengelh (subscriber, #33263) [Link]
And SVN provides the gun to hang yourself with? :-)
A proposed Subversion vision and roadmap Posted Apr 7, 2010 17:19 UTC (Wed) by cry_regarder (subscriber, #50545) [Link]
One bright day in the middle of the night
two dead boys got up to fight back to back they faced each other drew their swords and shot each other
|
|||||||||||||