a git plan, long term

[Brent Putman]

On 8/8/13 6:25 PM, Cantor, Scott wrote:
>
> The reason it's viewed as better for brancing is that it's low overhead to
> branch. Subversion takes some time to branch, particularly on slow links,
> and switching between branches is a heavier operation.
>
> Brancing and switching with Git is very fast and done offline.


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.  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).  It does have to hit the server, however, so that does add
some latency over git's local ops, and precludes off-line operations
certainly.

If you did the 'svn copy' against local paths, then yeah, that's going
to be very slow, and be proportional to the repo size, b/c you are in
fact making a full filesystem copy locally.  But I would never do that
for precisely that reason.



> That said, I don't find it very advantageous to branch like that because I
> don't trust merging (which is why I use neither svn nor git very
> effectively, unlike you and most others). That's one of those things you
> either trust or you don't, and it's very hard to achieve that trust when
> you've had nothing but broken merges whenever you've tried it. A hundred
> conflicts is not going to install that confidence.

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.