Re: The essential problems of moving from CVS

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Jan 16, 2010 at 12:25:30PM +0900, Curt Sampson wrote:
 > > For me at least it's not so much checkouts that's a problem as not
 > > being able to selectively update or revert subtrees, particularly in
 > > pkgsrc.
 > 
 > Well, from a git point of view, this simply doesn't make sense.

When someone needs to be able to do something, and they're told that
what they want to do doesn't make sense in the model your tool
provides, the obvious conclusion is that the tool is not suitable.

 > What you're saying when you do this is that you want only part of a
 > commit, and parts of other commits. That means you want a modified
 > working tree. You can generate a patch from a commit and then tweak
 > it to add or remove only the bits you want, and then you're left
 > with an appropriately modified working tree, I guess.

Yes, you can revert a subtree by patching. Then it's a local
modification and you have to be very sure it doesn't get pushed back
to the master repository. Which means you have to develop without it
and then apply it on top of your real changes in a different branch.
This means, among other things, that you need to commit every time you
want to test anything. I've done this, it's a big hassle, it involves
a lot of administrative overhead and if one takes a less involved
approach it's extremely easy to slip up and accidentally merge and
push the reversion.

What I want is to be able to revert, or maybe just patch, a subtree in
my working copy and have the SCM tool ignore that subtree (perhaps
warn or error if it becomes modified) while I work elsewhere. And I
suspect that I'm not the only person who wants this; with pkgsrc it's
often necessary to revert one or two broken packages in order to be
able to build something else that needs immediate updating.

(Updating a subtree is mostly interesting only because updating the
whole tree is slow. However, that's a legitimate concern.)

The alternative to subtree support appears to be to make each pkgsrc
package a separate repository, along the lines of the way X got split
up, but that's a complete non-starter, especially for pkgsrc.

 > > Another related problem is that you can't really use one tree
 > > to hack independently on, say, sh and sail(6), because if you commit
 > > the changes they get mixed together...
 > 
 > Not at all, in git, if you use its features designed just for this sort
 > of thing. Add only what you want to commit (e.g., only the sh changes)
 > to the index, commit, and the sail(6) changes won't be committed. The
 > stash command can help with this sort of thing, too.

Sure, you can commit subtrees. But if I commit sh, then commit sail,
then commit sh again, I need to use branches to avoid having the sail
commit depend on (and thus become inseparable from without a pile of
additional hassle) the sh commit. Using branches is fairly cheap, but
it's not free, it offers a lot of new ways to make mistakes, and it
makes it harder to keep track of all the half-finished things you have
in progress at once.

 > > And another somewhat more tangentially related problem (that topgit
 > > might also fix) is that you can't really keep local patches, like the
 > > gross hack I need for the tulip ethernet in my test machine, in the
 > > same tree that you use for development and commit.
 > 
 > Git actually excels at this sort of thing. Say 'master' is the main
 > branch, and 'local' is the branch that contains your local patches.
 > Here's the workflow.
 > 
 >     1. Switch to master branch and pull. Do any testing (compile or
 >     whatever) you care to here.
 > 
 >     2. Switch to 'local' branch and rebase to master. This brings in all
 >     of the new changes, and lets you merge your local patches if they
 >     need merging.

...or just merge with the master branch; there's no need for rebase.

 >     3. Hack away on whatever, and test until you're happy.
 > 
 >     4. When ready to commit, switch back to master branch, and do
 >     any testing/changes you need to do here to eliminate dependencies
 >     on your patches.

Well, yes, that's the issue, isn't it? The point is to keep the local
patches separate, and you haven't provided a means for doing that
other than "eliminate dependencies on your patches".

-- 
David A. Holland
dholland%netbsd.org@localhost