[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: excellent GIT video

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-11-02 09:05:24 CET

Garance A Drosihn <drosih@rpi.edu> writes:
> One key thing about GIT is that you want to commit early, and commit
> often. This works quite well with GIT, because you are NOT committing
> to any official repository. You're just telling GIT "remember these
> four lines as a single change". Or "remember that this file appeared
> and that file disappeared as a single change".
> You don't have a temporarily broken build, unless you're crazy
> enough to build it yourself (from your own local repository) when
> you know damn well that it won't compile. You're never breaking
> any build in any other repository, because YOU CAN'T TOUCH ANY
> OTHER REPOSITORY. Other repositories *pull* specific revisions from
> your repository -- and they only do that once you tell them which
> revision is safe for them to pull from you. Yes, you could tell
> them to pull a revision which you know will break their build, but
> you would only do that a few times before they would blacklist your
> email address.
> That is a significant change in mindset for those of us who are used
> to committing changes into TheOneTrueRepository(TM) for our projects.
> To us, a commit is a scary thing that BETTER NOT BREAK THE BUILD!
> But once you get past that new mindset, I suspect it's pretty easy to
> have project management work fairly well in GIT. We're used to
> "commit when you have it working right". GIT assumes "commit early
> and commit often -- even when it isn't working".

Note that this is how we're working in the Subversion repository right
now. You make a branch, do your work there, and then push ("pull",
whatever) the changes to trunk when they're ready. The developer who
made the change could do that merge, or someone else could, it doesn't
matter. The point is that this method works fine with Subversion.
Commits are certainly not inherently "scary things".

So this mindset is not new, and not unique to GIT.

What is cool about GIT is that there is no bureaucratic overhead to
getting branch access to the repository, since there isn't any "the
repository". You create your own repository whenever and wherever you
want, and then the merges take place between repositories.

> I'm not sure I would want to switch completely to way GIT works, but I
> can see some of the benefits from it. I suspect there's a number of
> good ideas which could be transplanted from GIT to svn.

Definitely agree.

But let's also not exaggerate the differences. The idea of "Don't
Break The Build" has acquired this mythical status, as though no
half-baked change can ever be put within five miles of the master
source code, for fear that Something Bad might happen. It's not like
that. The only thing that matters is to not break the build *of those
lines of development that are designated as being in semi-releaseable
state at all times*.

In Subversion's own repository, that's "trunk" and some of the release
branches (e.g., "branches/1.4.x/", etc). In other repositories (SVN
and otherwise), it might mean something entirely different. This is a
matter of policy, not of VC system.

> I have CVS/svn usage so ingrained that I'm not completely comfortable
> with making commits of code that I know will not work.

Huh? I have no problem making commits that I know won't work, if I
know that I'm committing them to a branch that's not expected to work.

The problem you're having is not, I think, due to SVN or CVS as
opposed to GIT. It's due to overly-rigid branch policy.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 2 09:05:37 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.