Garance Drosihn wrote:
> 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.
A broken build isn't only a problem when at the time of the break. If
you are coming back later and using a tool like git-bisect to narrow
down a regression, hitting a broken tree state in the middle will mess
you up. So, "it's okay to break the build because you're always working
on a private branch" doesn't really apply.
Anyway, I think I was wrong that git wants you to commit a rename before
committing an ensuing edit, so the point is moot. In the world of
heuristic rename detection, a query tool should be able to notice: "gee,
90% of the content you added to this new file was removed from this
other file in the same commit; I bet it's the source of the rename.
I'll keep displaying the file history along that path." Such a
heuristic doesn't have to search the whole tree, only the changes made
during one commit, so it can be fast.
On Fri, 2007-11-02 at 06:53 -0700, Micah Elliott wrote:
> http://lwn.net/Articles/246381/
Heh. "Change your workflow! Then git will be awesome!" If this is
working, then KDE developers must be really unhappy with svn.
Linus doesn't see it that way, of course. He thinks his workflow is
really fundamentally better than anyone else's, to the point where he
feels free to be abusive to anyone who doesn't adopt his approach. I
think it's a failing of geek culture that we see people like him and
Theo at the head of high-profile projects.
> Again, privacy. Linus' argument is that a big problem is that
> branches are globally visible in the centralized model.
Randal talked about this too. Facilitating the making of private
branches can be a boon in some cases, such as when you have insecure
developers--but if it's easier to make a private branch than a public
one, you can expect your overall development process to be much more
obscure.
A similar argument is that you can't prevent the creation of private
branches--people will use tools like tailor or svk to do it themselves
using your repository. The point is that this is harder than creating a
public branch, at least the first time, so a lot of developers will just
create public branches, and your process remains transparent.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 2 16:33:44 2007