On 5/1/12 16:01 , PJ Weisberg wrote:
On Tue, May 1, 2012 at 3:07 PM, Rich Pixley<rich.pixley@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html