You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2007/10/31 14:28:12 UTC
excellent GIT video
Subversion devs: there's a fabulous video up on youtube now, where
Randal Schwartz (famous perl hacker) gives a tech-talk about GIT:
http://youtube.com/watch?v=8dhZ9BXQgc4
No, this isn't entirely off-topic. A number of us have discussed
"stealing" various features from distributed version control systems,
and this talk is really something worth digesting. Unlike the awful
GIT talk given by Linus Torvalds earlier this year (where he spent
lots of time cursing subversion and insulting his audience), this talk
is all technical... no political agenda. Randal explains the
architecture of the system, why it's cool, and how one uses it. It's
a fascinating talk. (Well, fascinating to people who think about
version control, I guess!)
I know that everyone is focused on finishing svn 1.5 -- I just wanted
to share this link with the community so that if you *do* find an hour
of free time, you have something worthwhile to watch and think about.
Put it on your iPod or something, watch it on the train. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 1:05 AM -0700 11/2/07, Karl Fogel wrote:
>Garance A Drosihn <dr...@rpi.edu> writes:
> > One key thing about GIT is that you want to commit early, and
> > commit often.
> > 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!
>
>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.
Well, I didn't meant to say it is a new idea for all subversion users
or that it is a change which requires GIT. But for *some* developers
in *some* projects this is a pretty major paradigm shift (woo). And for
those developers, I think it is useful to wave a flag around explicitly
pointing out this difference in philosophy, or they will keep thinking
about commits the same way they have always thought about them.
I also found this was a significant point which was not presented at
all well by Linus. Some features are presented as if they are magical
capabilities of GIT, and yet (IMO) those features are not really tied
to GIT, and they are not magical. They are possible due to "commit
early and commit often". And while GIT promotes that behavior, it
seems to me that GIT is not required to support it. And conversely,
if developers switch to GIT but do *not* change their own behavior,
then they won't learn much from their experience with GIT. It'll just
be CVS with different commands.
I (for one) certainly had trouble understanding how GIT could do many
of the things that Linus bragged about, until I realized just how
important this "commit early and commit often" behavior was to almost
everything he talked about. If someone creates their on branch in
GIT, and then works on it for three months before they try to merge
all that work back into the main branch, then they are going to have
just as much trouble with GIT as they would have with subversion.
> > 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.
I'm thinking more of what happens once the work is merged into a
main branch. Let's say a tiny part of a much bigger change is to
move a subroutine from one source-file to some other source-file. I
want that move to show up as a separate commit, so that the SCM can
(all by itself) annotate that "this subroutine was the one originally
written in 1997 and moved to this file in 2007", and not mistakenly
claim "This routine was written for the first time in 2007". That is
a feature which GIT brags about, and which strikes me as very useful.
But let's say that someone comes along later, and is trying to pin
down where some obscure bug was introduced to the larger project.
*Very* often, the easiest way to do this is to do a binary search
through commit-history. "Did the bug exist in repo revision #200?
No. Revision 300? Yes. Revision 250? No." [etc]. In *that*
context, I don't want to waste the time of that developer by having
them pick some revision number which I know is not going to compile.
Note that I *do* want the commit to be there, for the best results
from annotate. But I don't want anyone to waste their time trying
to compile that specific revision. That's why I was thinking of
maybe having something like "subcommits". Some way to save a small
part of some larger change, while making it clear that that specific
commit isn't going to work well for anyone.
disclaimer: I tend to type too much, and I tend to sound like I'm
arguing when I don't mean to be. Apologies if I'm doing that here.
I'll now go and watch Randal's excellent presentation. :-)
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman wrote:
> On 11/2/07, Micah Elliott <md...@micahelliott.com> wrote:
>
>> Again, privacy. Linus' argument is that a big problem is that
>> branches are globally visible in the centralized model. Most
>> agree that "commit early, commit often" is desirable, but that's
>> restricted if your micro-commits are visible to the world, even
>> if it's only your own buggy branch. The picture to keep in mind
>> is that of a developer wanting to make a bunch of silly,
>> potentially embarrassing changes to his local branch while on a
>> spike, and later sending a super-commit (non-local) agglomerating
>> and cherry-picking only the "smart" net result of all the
>> micro-changes. This model better allows a developer to use the
>> VCS as a scratch pad to record whimsical direction.
>
> Are programmers really that prone to embarrassment? I mean, if you
> create a private branch in central repository, and tell your peers
> that you're just experimenting or saving scratch-work, what's the big
> deal? I've never thought of developers as so ... insecure.
You've been at Google too long.
It is not rare for developers (perhaps your so-called 80%[1], who are,
despite claims otherwise, still human) to have insecurity issues. That's
what drives them to work in isolation at all -- fear of peer review due to
lacking skills, or fear of losing a job because the boss pays for new
features and bug fixes and not risky "what if" innovation.
-- C-Mike
[1] http://blog.red-bean.com/sussman/?p=79
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: excellent GIT video
Posted by Mattias Engdegård <ma...@virtutech.se>.
"Ben Collins-Sussman" <su...@red-bean.com> writes:
>Are programmers really that prone to embarrassment? I mean, if you
>create a private branch in central repository, and tell your peers
>that you're just experimenting or saving scratch-work, what's the big
>deal? I've never thought of developers as so ... insecure.
Assuming secure and confident programmers, the main benefit of a
private changeset tree is that it allows you (the programmer) to edit
a big change into a tidy sequence of atomic bisectable changes, taking
the source tree from one state into another in small neat steps.
This is not at all to hide embarrassments, but actual work you do for
the benefit of your coworkers to make it easier for them to review your
work and to merge it with their own potentially conflicting changes.
It can also be seen as "code PR" work, to convince colleagues that your
clean changes are worth including into the main line of development.
As an extra added benefit, the "scratchpad" changes do not consume central
resources in any way - neither network bandwidth, server CPU, disk space,
nor name/version number space.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Karl Fogel <kf...@red-bean.com>.
"Ben Collins-Sussman" <su...@red-bean.com> writes:
> On 11/2/07, Micah Elliott <md...@micahelliott.com> wrote:
>> Again, privacy. Linus' argument is that a big problem is that
>> branches are globally visible in the centralized model. Most
>> agree that "commit early, commit often" is desirable, but that's
>> restricted if your micro-commits are visible to the world, even
>> if it's only your own buggy branch. The picture to keep in mind
>> is that of a developer wanting to make a bunch of silly,
>> potentially embarrassing changes to his local branch while on a
>> spike, and later sending a super-commit (non-local) agglomerating
>> and cherry-picking only the "smart" net result of all the
>> micro-changes. This model better allows a developer to use the
>> VCS as a scratch pad to record whimsical direction.
>
> Are programmers really that prone to embarrassment? I mean, if you
> create a private branch in central repository, and tell your peers
> that you're just experimenting or saving scratch-work, what's the big
> deal? I've never thought of developers as so ... insecure.
I have to agree with Micah here. I keep running into programmers --
pretty good ones -- who are not comfortable with the wide-open,
peer-review-at-any-time process that we're used to in the open source
world. They have a different personality than the one we're used to,
but that's because our environments have selected against that kind of
programmer. It doesn't mean that kind of programmer is bad, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Tor Ringstad <to...@pvv.org>.
[Ben Collins-Sussman]
> Are programmers really that prone to embarrassment? I mean, if you
> create a private branch in central repository, and tell your peers
> that you're just experimenting or saving scratch-work, what's the
> big deal?
Amen.
In my company, we've created {branches,tags}/personal/<username>
directories, and told people that there they can branch and tag to
their hearts delight. (The top-levels of branches/tags are reserved
for "officially sanctioned" stuff.)
A few people actually use this regularly (perhaps 10%), but most,
regrettably, don't. The reason is certainly not embarrasment, but the
simple fact that merging is not yet trivial enough.
When we switched from CVS to Subversion a couple of years ago, we had
big hopes for those "cheap branches", because branching in CVS was
nothing like cheap, and you'd have to be insane to even think of using
them for small-scale, short-lived stuff. We thought that, as soon as
we switch to Subversion, it would be easy to convince people to do
their day-to-day work on branches. Not surprisingly, we soon
discovered that *branching* isn't the problem, it's the *merging*
that's hard.
- Tor Ringstad -
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 11/2/07, Micah Elliott <md...@micahelliott.com> wrote:
> Again, privacy. Linus' argument is that a big problem is that
> branches are globally visible in the centralized model. Most
> agree that "commit early, commit often" is desirable, but that's
> restricted if your micro-commits are visible to the world, even
> if it's only your own buggy branch. The picture to keep in mind
> is that of a developer wanting to make a bunch of silly,
> potentially embarrassing changes to his local branch while on a
> spike, and later sending a super-commit (non-local) agglomerating
> and cherry-picking only the "smart" net result of all the
> micro-changes. This model better allows a developer to use the
> VCS as a scratch pad to record whimsical direction.
Are programmers really that prone to embarrassment? I mean, if you
create a private branch in central repository, and tell your peers
that you're just experimenting or saving scratch-work, what's the big
deal? I've never thought of developers as so ... insecure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by John Peacock <jo...@havurah-software.org>.
Micah Elliott wrote:
> Again, privacy. Linus' argument is that a big problem is that
> branches are globally visible in the centralized model. Most
> agree that "commit early, commit often" is desirable, but that's
> restricted if your micro-commits are visible to the world, even
> if it's only your own buggy branch.
Yeah, that is one way I'm using SVK, and I even added a --review option
so you can --lump all of your local changes and edit the combined commit
message to be sensible. There are strong reasons why visibility is good
for a project as a while and other strong reasons why quiet internal
contemplation is better for the individual developer. Native Subversion
currently really only permits visible branches (though you could easily
use authz to limit that too).
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Greg Hudson <gh...@MIT.EDU>.
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
Re: excellent GIT video
Posted by Micah Elliott <md...@micahelliott.com>.
On 2007-11-02 Ben Collins-Sussman wrote:
> The important thing about GIT and other DVCSs is that they make
> merging {simple, trivial, elegant, pleasant} right from the
> start.
They also make it private. This is a key that I found Linus
talking about with KDE here:
http://lwn.net/Articles/246381/
> We can talk all we want about how we can emulate the same
> freedom in Subversion or CVS by "just committing lots of
> half-baked changes to a private branch"... but users are
> *averse* to that.
Again, privacy. Linus' argument is that a big problem is that
branches are globally visible in the centralized model. Most
agree that "commit early, commit often" is desirable, but that's
restricted if your micro-commits are visible to the world, even
if it's only your own buggy branch. The picture to keep in mind
is that of a developer wanting to make a bunch of silly,
potentially embarrassing changes to his local branch while on a
spike, and later sending a super-commit (non-local) agglomerating
and cherry-picking only the "smart" net result of all the
micro-changes. This model better allows a developer to use the
VCS as a scratch pad to record whimsical direction.
--
_ _ ___
|V|icah |- lliott
" " """
mde@MicahElliott.com <>< http://MicahElliott.com
PGP: 0x7C07CBF0 ICQ: 369060435 Linux/Ubuntu: 417195/12440
HackerKey: v4sw6YUPCJhw5ln5pr7OPck2ma9u8Lw3m5l6Ui2e7t3b8LDMOen6a3XsMRr5
Re: excellent GIT video
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 11/2/07, Karl Fogel <kf...@red-bean.com> wrote:
> 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".
The important thing about GIT and other DVCSs is that they make
merging {simple, trivial, elegant, pleasant} right from the start. We
can talk all we want about how we can emulate the same freedom in
Subversion or CVS by "just committing lots of half-baked changes to a
private branch"... but users are *averse* to that. Not because of a
"rigid policy mindset", but because merging back (or heaven forbid --
merging back and forth!) has always been so darn hard. DVCS removes
that barrier. And hopefully SVN 1.5 will do the same. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Karl Fogel <kf...@red-bean.com>.
Garance A Drosihn <dr...@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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Mark Reibert <sv...@reibert.com>.
On Fri, 2007-11-02 at 00:25 -0400, Garance A Drosihn wrote:
> 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".
This same effect can be achieved with just about any tool that supports
branching. ClearCase with UCM works very naturally this way.
--
----------------------
Mark S. Reibert, Ph.D.
svn@reibert.com
----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 1:27 AM -0400 11/1/07, Greg Hudson wrote:
>27 minutes in, we learn that git doesn't track explicit renames, but
>instead intuits them (as well as copies) from matching file contents.
>
>I assume that means if you're doing a tree reorg, you really want to
>commit the tree operations separately from any file modifications you
>want to do to the renamed files (e.g. because you're moving Java source
>and renaming the classes at the same time), or git won't be able to
>tell. That might in turn result in a temporarily broken build, but
>that's a minor point which you could easily plaster over with branches.
I haven't seen this video yet, but I did sit on another presentation
on GIT which was about two orders of magnitude more useful than the
rant^H^H^H^Htalk that Linus gave at Google.
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".
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.
I have CVS/svn usage so ingrained that I'm not completely comfortable
with making commits of code that I know will not work. But maybe we
could have some idea of "subcommits".
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by David Waite <dw...@gmail.com>.
On 10/31/07, Greg Hudson <gh...@mit.edu> wrote:
>
> 27 minutes in, we learn that git doesn't track explicit renames, but
> instead intuits them (as well as copies) from matching file contents.
>
> I assume that means if you're doing a tree reorg, you really want to
> commit the tree operations separately from any file modifications you
> want to do to the renamed files (e.g. because you're moving Java source
> and renaming the classes at the same time), or git won't be able to
> tell. That might in turn result in a temporarily broken build, but
> that's a minor point which you could easily plaster over with branches.
This is what I originally thought as well, that commits would be broken into
move/change pairs. I believe they do simple heuristics instead, most
probably like OS X's aliases - if you move a file the system will perform
some business logic to track down where it is, but if you move a new file in
its place it assumes you meant to replace the original. E.g. look at files
that were created in the same rev the one you had disappeared.
In practice, I've found tracking renames to not be worth the pain. If you
need to track copies and moves, you wind up having special commands that
have to be learned in order to do so. Without those, you can take changes to
a working copy (including new and missing files) to be intentional, and
committing becomes a snapshot operation.
The biggest complaint I have heard from users of subversion is that getting
snap-shot behavior is too error prone. Some will have Mac OS X bundles that
they wish to manage, or document directories they want to reorganize, or
attempt to do java development but don't enable an appropriate plugin. A lot
of these issues get solved with a single root .svn tracking directory, but I
bring it up for one reason:
Its important to not make getting work committed hard.
Indeed, this is my opinion, but I believe its better to make complex merges
require more education than the complicate up commits.
Maybe this means the person who reorganizes the class layout of a widely
followed java project runs a few commands or runs a special IDE plugin or
set of commands so that metadata on moves is more directly indicated to
tools. Maybe this means the same person just tells others that a change is
coming at such-and-such time, and to react accordingly.
The major point is that this feels like a variation of Subversion's
> mistake in tracking copies rather than renames. Randal says that if you
> copy a file to three different places and then change it in one place,
> you probably want to change it in the others, but my intuition says
> that's a very dangerous assumption.
Yeah, that had me scratching my head as well. I might want to be notified
that the change could be applied in more places, but such a heuristic is too
complex to make automatic.
On a less serious note, as someone who hasn't been on a plane in years,
> I've gotten really tired of "I can work on an airplane" as the poster
> child for disconnected operation. I'm sure it's very important to
> consultants who are jetting around the country every other week--say, to
> give talks about distributed version control tools--but there are a
> large class of developers who could care less whether they can work on
> an airplane.
As someone who has used git for contributing to a few projects now, there is
a bit more to it. While private branches can be considered bad for
structured environments, they are incredibly good for open source
environments. I recently had a bug in a local branch which I spent a long
time fixing, including breaking individual commits out into smaller pieces
to find out when certain regressions (turned out to be two) occurred.
I might have not wanted all of that sort of experimentation to appear in a
public repository. Which means, I wouldn't have used the tool available to
help me solve the problem. In that particular case, disconnected operation
really helped me.
The usage model feels a bit like darcs's, where repositories are
> synonymous with working copy metadata. But, if I'm remembering right, a
> darcs wc/repo only covers one line of development, whereas a git wc/repo
> covers many.
Branches can point to a remote location for push/pull ops, such a branch is
said to be 'tracking'. You can track many different branches, with
commonalities being reduced to the same objects in the object database.
-David Waite
Re: excellent GIT video
Posted by Ask Bjørn Hansen <as...@develooper.com>.
On Oct 31, 2007, at 10:27 PM, Greg Hudson wrote:
> On a less serious note, as someone who hasn't been on a plane in
> years,
> I've gotten really tired of "I can work on an airplane" as the poster
> child for disconnected operation. [...]
I don't think I've ever gotten any worthwhile code done on an
airplane, but as others pointed out: it's just a substitute for "bad
connectivity".
I often use git or svk to manage my local working copy. I'm
completely wedded to the "One True Repository" model of managing the
code though, so all my projects are still in Subversion.
I've found myself to be supremely productive when I've been without
net access but with a local repository. No distractions + commit
access = yay. But that probably just says something about how much
trouble I have focusing. :-)
In particular with git I've noticed that I'm much much more likely to
study old history (diffs and commits logs) because it's so darn fast.
Not having the frequent multi second wait really makes a big difference.
For the "track content, not filenames" thing: In my limited
experience it works really well. It felt pretty scary to me at first,
but so far it's never been an issue and it's nice to be able to "just
move code around" rather than the usual "hmn, now I'm moving 90% of
the functions in this file to the other file, I better stop what I'm
doing and go do a rename first" disruption.
- ask
--
http://develooper.com/ - http://askask.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Mark Reibert <sv...@reibert.com>.
On Thu, 2007-11-01 at 11:41 -0400, Greg Hudson wrote:
> >From a theoretical viewpoint, I'm not sold. I don't believe you can
> create reliable rename heuristics based purely on tree state. A simple
> query operation like "show me this file's history and don't stop at
> renames" seems likely to erroneously bottom out a lot, or erroneously
> show you a file that wasn't actually part of the history at all. And a
> merge in the presence of tree reorganizations (on either side) seems
> prone to catastrophic failure. That's certainly no worse than
> Subversion--but when Subversion's poor tree merging is a major selling
> point for alternative version control systems, I think you want to do
> better than you can with heuristics.
Linus would tell you renames do not matter; rather tracking file content
is important.
I am not sure how I feel about that. On one hand, it is not difficult to
dream up realistic scenarios where this makes sense. For example, if I
move a routine from one file to another, Git will track this nicely
whereas a file-based versioning tool will just see (unrelated) changes
in two files. On the other hand, it just feels weird!
--
----------------------
Mark S. Reibert, Ph.D.
svn@reibert.com
----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2007-11-01 at 10:41 -0400, Augie Fackler wrote:
> It doesn't actually totally hork up if you do a rename and an edit. My
> friend that uses git for *everything* says that it uses a heuristic to
> determine file ancestry across renames. Supposedly it works really
> really well. I've not used git personally, so I can't offer much
> commentary on how well this works in practice. What I've heard is that
> they track renames and copies about as well as Subversion.
Okay, here's the kool-aid post:
http://permalink.gmane.org/gmane.comp.version-control.git/217
The git "plumbing" doesn't track renames or copies or even relationships
between different versions of files at the same pathname. It has enough
information to construct the tree content for each revision, and
everything beyond that is derived. Tom Lord would definitely
disapprove; this is an extreme form of the "tree-oriented" repository
model. The packed form of the repository might use deltas between
objects which happen to have the same pathname in two different versions
of a tree, or it might use something deltas between two objects at
different pathnames which weren't related at all except that they
happened to generate a nice delta. (I have no idea how it finds these
efficient diffs; not going to worry about that now.)
A positive consequence from the Linux kernel developers' point of view
is that you can import a series of .tar.gz files (of, say, the Linux
kernel before it was under version control) and your repository model is
as high-quality as if you've been using git from day one. You can apply
changes with a dumb (about trees) tool like patch(1) and as long as you
get to the right tree state, you're golden. It's not clear how many
other projects care about supporting that kind of workflow, but maybe
some do. Certainly, it's a model which will integrate well with a wide
variety of tools that don't know jack about version control.
The "porcelain" is then responsible for deriving file movement at query
time or merge time. More generally, you can try to derive *content*
movement, such as when a block of code moves from one file to another
file, or is refactored from several places into one.
From a theoretical viewpoint, I'm not sold. I don't believe you can
create reliable rename heuristics based purely on tree state. A simple
query operation like "show me this file's history and don't stop at
renames" seems likely to erroneously bottom out a lot, or erroneously
show you a file that wasn't actually part of the history at all. And a
merge in the presence of tree reorganizations (on either side) seems
prone to catastrophic failure. That's certainly no worse than
Subversion--but when Subversion's poor tree merging is a major selling
point for alternative version control systems, I think you want to do
better than you can with heuristics.
From a practical viewpoint, I'm curious about how use cases like
Pidgin's would have panned out. Pidgin (aka Gaim at the time) converted
their CVS tree to svn, started doing a bunch of file renames which they
wished they could have done a long time ago in CVS, ran into merge
spaghetti because svn can't merge across tree reorgs, and ditched svn
for Monotone in pretty short order. When they run into technical
hurdles with Monotone like dodgy Trac integration, they don't look back
because "at least it's not svn." Would Git's heuristics have done a
good enough job to prevent them from developing such a deep antipathy
towards the tool, or would it have been the same experience?
You can find happy satisfied users of any established version control
tool or it would quickly become disestablished, but that usually just
means they haven't tried to do anything the tool doesn't do well, or
came in with a good understanding of the tool's limitations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Augie Fackler <du...@gmail.com>.
On Nov 1, 2007, at 1:27 AM, Greg Hudson wrote:
> 27 minutes in, we learn that git doesn't track explicit renames, but
> instead intuits them (as well as copies) from matching file contents.
>
> I assume that means if you're doing a tree reorg, you really want to
> commit the tree operations separately from any file modifications you
> want to do to the renamed files (e.g. because you're moving Java
> source
> and renaming the classes at the same time), or git won't be able to
> tell. That might in turn result in a temporarily broken build, but
> that's a minor point which you could easily plaster over with
> branches.
It doesn't actually totally hork up if you do a rename and an edit. My
friend that uses git for *everything* says that it uses a heuristic to
determine file ancestry across renames. Supposedly it works really
really well. I've not used git personally, so I can't offer much
commentary on how well this works in practice. What I've heard is that
they track renames and copies about as well as Subversion.
Augie
>> <snip>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Talden <ta...@gmail.com>.
I think that Subversion needs to look at SVK very closely and consider
the value in consuming some of its differences. We absolutely need a
new working copy model (and clearly that has been taken on-board from
observed discussions).
Perhaps a better working copy really should include repository clone.
We might want to narrow that definition to being a filtered set of
content by perhaps discarding content that is not relevant to the
subtree that has been checked out (just to manage volume for those
users where the total volume is far too large to clone at every
checkout).
I certainly don't like the idea of losing the ability to express
explicit copies/renames. We probably do want to support 'local
commits' to support folding a sequence of dependent changes into a
single repository commit (mixing in some of what is missing in the svn
client but which is supported currently via svnmucc).
--
Talden
On 11/2/07, John Peacock <jo...@havurah-software.org> wrote:
> Greg Hudson wrote:
> > A distributed version control system might work very poorly when off the
> > net, e.g. if it frequently has to go off and contact other people's
> > repostories in order to provide history information. A centralized
> > version control system might work very well when off the net, e.g. if
> > you keep a cached copy of the whole repository. Two very different axes
> > of functionality.
>
> Except SVK allows me to have a full mirror of the main repo, so it is
> not "distributed" in the sense you are using. SVK really is a
> disconnected Subversion client and if Subversion grew that capability
> natively, I'd be a happy camper because it is a very nice way to work.
>
> I'm not trying to evangelize about SVK (and I've been using Subversion
> longer than I have been using SVK). I am also one of the primary voices
> of caution against moving the Perl repo to a Git backend, so I am
> automatically biased against Git... ;-)
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by John Peacock <jo...@havurah-software.org>.
Greg Hudson wrote:
> A distributed version control system might work very poorly when off the
> net, e.g. if it frequently has to go off and contact other people's
> repostories in order to provide history information. A centralized
> version control system might work very well when off the net, e.g. if
> you keep a cached copy of the whole repository. Two very different axes
> of functionality.
Except SVK allows me to have a full mirror of the main repo, so it is
not "distributed" in the sense you are using. SVK really is a
disconnected Subversion client and if Subversion grew that capability
natively, I'd be a happy camper because it is a very nice way to work.
I'm not trying to evangelize about SVK (and I've been using Subversion
longer than I have been using SVK). I am also one of the primary voices
of caution against moving the Perl repo to a Git backend, so I am
automatically biased against Git... ;-)
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2007-11-01 at 16:16 -0400, John Peacock wrote:
> I'm using "disconnected" to mean "work on my own stuff
> for a while and not break the buildboxes with my stupidity."
Traditionally that is referred to as "distributed."
A distributed version control system might work very poorly when off the
net, e.g. if it frequently has to go off and contact other people's
repostories in order to provide history information. A centralized
version control system might work very well when off the net, e.g. if
you keep a cached copy of the whole repository. Two very different axes
of functionality.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by John Peacock <jo...@havurah-software.org>.
Karl Fogel wrote:
> It's just a figure of speech, like the phrase "bus factor". "On an
> airplane" means "not having reliable Net access"; you don't actually
> have to be on an airplane for that to happen.
I've been using SVK for years, and now I'm using SVK at my new job and
doing a talk tomorrow to the rest of the team on why they might want to
do the same. I'm using "disconnected" to mean "work on my own stuff
for a while and not break the buildboxes with my stupidity." I have a
local branch for each bug ticket I work on and I push to the main repo
in as few chunks as possible (since this makes merging somewhat simpler).
Some of the merging pain will go away with 1.5.0, but I don't forsee
stopping using SVK anytime soon (unless my boss makes me). So don't
think that disconnected/distributed development is strictly for the
airborne or 'Netless... ;-)
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Talden <ta...@gmail.com>.
I work in New Zealand with a US head office. Several of us are mobile
users who will not always have immediate access to connectivity and
every now NZ falls of the face of the planet (well off the internet
which is the same thing isn't it - and ok, not the whole country but
usually just one or two networks will go dark, but hey - it's much
more conventionally sensationalist to suggest that NZ goes dark every
other moment)...
Being able to work away from the network is a critical component of
version control for many of our developers. [That said, we've just
been acquired and will probably have to move to (scary music)
ClearCase to fit with the new corporate mantra. Sigh - where did I put
that CV]
Of course for all personal work I will be sticking with Subversion (or
maybe Mercurial, or Bazaar).
PS: To continue with the sensationalist exaggeration - In NZ it's
quicker to ship our network traffic by carrier-pigeon due to the poor
telecommunications infrastructure. In NZ, broadband just means a
pigeon with a bigger wing-span.
--
Talden
On 11/2/07, Karl Fogel <kf...@red-bean.com> wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
> > On a less serious note, as someone who hasn't been on a plane in years,
> > I've gotten really tired of "I can work on an airplane" as the poster
> > child for disconnected operation. I'm sure it's very important to
> > consultants who are jetting around the country every other week--say, to
> > give talks about distributed version control tools--but there are a
> > large class of developers who could care less whether they can work on
> > an airplane.
>
> It's just a figure of speech, like the phrase "bus factor". "On an
> airplane" means "not having reliable Net access"; you don't actually
> have to be on an airplane for that to happen.
>
> It may also be the case that you've not been anywhere without Net
> access in years, but that's not only due to your not flying :-).
>
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Karl Fogel <kf...@red-bean.com>.
Greg Hudson <gh...@MIT.EDU> writes:
> On a less serious note, as someone who hasn't been on a plane in years,
> I've gotten really tired of "I can work on an airplane" as the poster
> child for disconnected operation. I'm sure it's very important to
> consultants who are jetting around the country every other week--say, to
> give talks about distributed version control tools--but there are a
> large class of developers who could care less whether they can work on
> an airplane.
It's just a figure of speech, like the phrase "bus factor". "On an
airplane" means "not having reliable Net access"; you don't actually
have to be on an airplane for that to happen.
It may also be the case that you've not been anywhere without Net
access in years, but that's not only due to your not flying :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: excellent GIT video
Posted by Greg Hudson <gh...@MIT.EDU>.
27 minutes in, we learn that git doesn't track explicit renames, but
instead intuits them (as well as copies) from matching file contents.
I assume that means if you're doing a tree reorg, you really want to
commit the tree operations separately from any file modifications you
want to do to the renamed files (e.g. because you're moving Java source
and renaming the classes at the same time), or git won't be able to
tell. That might in turn result in a temporarily broken build, but
that's a minor point which you could easily plaster over with branches.
The major point is that this feels like a variation of Subversion's
mistake in tracking copies rather than renames. Randal says that if you
copy a file to three different places and then change it in one place,
you probably want to change it in the others, but my intuition says
that's a very dangerous assumption.
I'm sure this has been explored ad infinitum on the git mailing lists;
I'm kind of curious how it pans out in practice. We know that
Subversion fails miserably in merging when there have been tree
operations on either side of the merge; this is because Subversion tree
merging is based on pathnames without little regard to object movement.
git merging is (apparently) purely based on file contents without regard
to pathnames, which I would expect to have different but still sometimes
terribly wrong behavior. I could be wrong; complex merging gives me a
headache if I think about it too hard.
On a less serious note, as someone who hasn't been on a plane in years,
I've gotten really tired of "I can work on an airplane" as the poster
child for disconnected operation. I'm sure it's very important to
consultants who are jetting around the country every other week--say, to
give talks about distributed version control tools--but there are a
large class of developers who could care less whether they can work on
an airplane.
The usage model feels a bit like darcs's, where repositories are
synonymous with working copy metadata. But, if I'm remembering right, a
darcs wc/repo only covers one line of development, whereas a git wc/repo
covers many.
The "rebase" operation is an interesting generalization of "cvs
update" (in the case where you have local modifications). I'm curious
how often the idea shows up in other DVCS tools as a way of avoiding
"bushy branches" during day-to-day development. darcs, of course,
rebases *everything* so that the view from any working copy is always a
linear list of changes.
On Wed, 2007-10-31 at 09:28 -0500, Ben Collins-Sussman wrote:
> Subversion devs: there's a fabulous video up on youtube now, where
> Randal Schwartz (famous perl hacker) gives a tech-talk about GIT:
>
> http://youtube.com/watch?v=8dhZ9BXQgc4
>
> No, this isn't entirely off-topic. A number of us have discussed
> "stealing" various features from distributed version control systems,
> and this talk is really something worth digesting. Unlike the awful
> GIT talk given by Linus Torvalds earlier this year (where he spent
> lots of time cursing subversion and insulting his audience), this talk
> is all technical... no political agenda. Randal explains the
> architecture of the system, why it's cool, and how one uses it. It's
> a fascinating talk. (Well, fascinating to people who think about
> version control, I guess!)
>
> I know that everyone is focused on finishing svn 1.5 -- I just wanted
> to share this link with the community so that if you *do* find an hour
> of free time, you have something worthwhile to watch and think about.
> Put it on your iPod or something, watch it on the train. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org