Re: Newbie grief

[Rich Pixley <rich.pixley@palm.com>]

On 5/1/12 16:01 , PJ Weisberg wrote:
> On Tue, May 1, 2012 at 3:07 PM, Rich Pixley<rich.pixley@palm.com>  wrote:
>
>> No, not a deploy system.  You use a deploy system to set up something like
>> multiple server http farms.  What I'm doing is more akin to porting the same
>> piece of software to 20 different operating system distributions.  I'm not
>> "deploying" the source code.  I'm developing it.
> I fail to see how you would end up with more than one branch per
> environment, though.  Fewer, if you do the merge before pushing your
> change back to the server.
>
> It sounds like you're asking for branches without names (or
> automatically assigned names like master-0, master-1, etc.).  I'm sure
> it's all very intuitive in Hg (which I know nothing about), but it
> sounds to me like a recipe for confusion.
I'm finding the reverse to be true.

In hg, I don't have to think about how many other branches or 
repositories there might be.  I don't have to track where the changes 
are.  And I don't have to do anything to add another repository to the 
mix or to remove one.  Trivial merges are trivial.  The view from any 
repository is identical, not just symmetric.  The things I want to do 
are all simple commands.  Pull from the cache, merge if necessary, do 
some work, push to the cache.  Repeat as necessary since there will be 
numerous collisions and merges since I'm working on multiple machines 
concurrently.  And eventually, push to central server.

With git, if I use the traditional triangle architecture, I have to 
manually name every repository and every branch uniquely, create fresh 
branches in every other repository when I create one new repository.  
Remove old branches from every other repository whenever I remove one.  
Track collisions manually, track which repositories have which changes 
manually, and be extra careful about moving changes around so that they 
don't collide or force merge commits because that screws up git 
histories.  In order to do a simple source code control task, I have to 
stop, formulate a plan for making things work in git that still ducks 
both the limitations and traps of git and still accomplishes my goal, 
and then execute that plan precisely, because recovery is difficult.

If I skip the standard git triangle merging architecture, I can collapse 
some of that bookkeeping by sharing a branch.  But the cost is that 
pushing, pulling, and merging become even more complex as I have to 
dodge more limitations, (essentially, pushing doesn't work, star 
networks don't work, etc.)

Trying to keep all of that bookkeeping in my head, or trying to remember 
all of those arbitrary and unnecessary limitations is more complicated.

I'll grant that some of this is unique to my current work flow.  But I 
think that a lot of it carries into other work flows as well.

--rich