a git plan, long term

[Cantor, Scott]

On 8/8/13 7:41 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>I see that Git is nominally faster b/c it's local, but svn isn't really
>slow in an absolute sense.  At least if you're doing the 'svn copy'
>against 2 server-side URL targets (e.g. svn copy
>https://server/repo/trunk https://server/repo/branches/foo), which is
>pretty much the only way I'd do it.

Yes, I agree.

>It's a fast, cheap, constant time
>operation, repo size doesn't matter. It's sub-second on any decent link
>(never tried on dial-up modem though...).  And then 'svn switch'-ing to
>it is similarly fast, since it doesn't have to do anything (no deltas to
>pull down).

But if you're switching the local copy, it does have to pull down the
different files once they diverge. With git, it's local, so switching back
and forth is much faster between two divergent branches.

>Yeah, if you merge and have a hundred conflicts, it's not going to
>matter which SCM you use, nothing's going to handle that for you.  I
>guess the trick is to not let yourself get to a hundred conflicts in the
>first place, by periodically over time merging the (smaller) deltas from
>A -> B, so when you go to do the final merge from B -> A, the conflicts
>are reduced or eliminated.  That is the theory at least.  It really
>depends on how much overlapping change is happening on the code you
>branched from and are later merging back to.

Yes. I guess I simply don't know how to organize my work to fit this style
of code evolution. The only time I seem to merge clean is when I
essentially haven't changed the original branch, and that's not really
merging, it's just waiting to commit.

Anyway, the point of git's design is to branch constantly, and I can't
even typically branch once without pain. I need to have the whole code
base "swapped in" and I don't find that as easy if I'm juggling branches.

-- Scott