Re: Newbie grief
- From
- Rich Pixley <rich.pixley@palm.com>
- Date
- May 3, 2012, 18:43 UTC
- Message-ID
- <4FA2D1D7.3020807@palm.com>
- In-Reply-To
- <CAJsNXTmo1B86nSm7u923jJuGX0zajz3iqVu-onANMN-5BE5DfQ@mail.gmail.com>
On 5/1/12 16:01 , PJ Weisberg wrote:
Show 14 quoted lines
> 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