Re: Your favorite version control software
On Fri, Mar 25, 2011 at 06:06:12PM +0100, Mathieu Malaterre wrote:
> On Fri, Mar 25, 2011 at 5:59 PM, Boyd Stephen Smith Jr.
> <email@example.com> wrote:
> > On 2011-03-25 11:39:17 Jason Hsu wrote:
> >>Why do you prefer Subversion for the central repository and git for laptops?
> > For laptops, or in any case where you may not have an active, reliable
> > connection to the central repository, subversion just fails. ?You can't
> > commit, branch, etc. ?All of the distributed VCSes support disconnected
> > operations, even if they aren't the default.
> Even with LAN access to your SVN server, try a svn-bisect and then
> compare it to a git-bisect.
I'll agree that git-bisect is pretty awesome, but I can do it with git-svn
when I need to. I also like git stash, and the line-by-line git add is
pretty great when I need it. All of that is accessible via git-svn.
> There is no going back to SVN, once you understand the whole
> decentralized approach. git merge just works. I do agree that setting
> up the git server to refuse most delete operation take some time and
Either I don't get it or I won't drink the Kool-Aid. It's hard to say
which. I understand the value of the decentralized approach for a
decentralized project. That includes many open source projects. I believe
that git is absolutely the best choice for the Linux kernel, for example.
On the other hand, I *really* value a repository-wide, monotonically
increasing version number. When I'm setting up source control for a
project, I'll always go with subversion. Even if everyone working on the
project uses git through git-svn and pulls changesets from one another, I
want the central repository to have sequential revision numbers for
commits. I want to be able to identify a revision number in a release that
indicates all of the commits of which it is composed (i.e. any number less
than that revision number). The whole GUID thing is fine for passing
changes around, but it's meaningless for a release.
So, yeah, git is great on the client side, but I want a central repository
that is more oriented toward points in time than changesets. I can have
both with git-svn.