a git plan, long term

[Brent Putman]

On 8/8/13 6:27 PM, Scott Koranda wrote:
> Given the size of the code base I suspect you will find SVN branching
> "like crazy"
> to be cumbersome and resource intensive. The reason is that in SVN a branch
> is mostly a copy.
>
> Git, on the other hand, uses an elegant and inexpensive technique so
> that branching
> is fast. You will not give creating a new branch just to explore,
> experiment, or make
> a small bug fix a second thought because it is so easy and fast.

I don't know how Git branching works, but as I said in my other note,
svn branching is also a very fast constant time operation, at least if
you are invoking it with remote URL targets. It's not really a "copy" in
the literal sense, it just adds a logical pointer.

On the other hand, if you do the 'svn copy' using targets in your local
working copy, it can be very slow, because it really is a local copy. 
Ironically when you check it in (assuming no immediate changes) it just
adds the cheap remote pointer as above.  So doing it that way is best
avoided, unless you really need both branches on your workstation
filesystem at the same time in parallel (the I/O cost is basically like
doing a 2nd checkout).


> I cannot do that with a SVN repository of any reasonable size. 

If you do it as a URL -> URL copy, it won't matter what the size is
since it doesn't actually do a copy.

It does have to hit the server, however, so that is a distinct
difference from Git.  And as Ian pointed out, does require commit access
to the centralized repo.



>
> P.S. One of my favorite git features is 'stash'--with one command I
> can take all the current uncommitted edits and have them stashed away
> safely while I go back to master, branch quickly, make a bug fix,
> commit it, push, then "unstash" and pick right up where I left off.
>


That does sound cool, at least certainly more convenient than manually
saving off diffs and then re-applying them to come back to where you were.