Centralized Storage, round 2

[Benno]

On Wed Sep 14, 2005 at 08:26:36 -0400, John A Meinel wrote:
>Benno wrote:
>...
>
>>>
>>>What I'm talking about is when a user wants to share the branch that
>>>they have on their machine, not a remote mirror.  I used to do this with
>>>Arch development.  Every time I committed, it was automatically on the
>>>web.  Then I decided I didn't want people hitting my machine, so I
>>>started using sourcecontrol instead.
>>>
>>>At work I still do this.  My coworker reads from the archive I commit
>>>to.  I read from the one he commits to.  Both locations are
>>>automatically backed up, without so much as an archive-mirror command.
>>
>>
>> FWIW, I use this model extensively with baz. If bzr is set to replace
>> baz, then I'm starting to get a bit concerned.
>>
>> Benno
>>
>
>Care to shed some light on what you are specifically concerned about?
>
>I personally am not terribly bothered by needing an extra "bzr push"
>after doing a few commits. Though I would prefer commit to put the files
>onto a remote host (I probably would just have a plugin that committed
>and pushed at the same time).

Getting a team of developers to switch to a new model and new set of
options is not terribly enticing. It requires a lot of work in redocumenting
procedures, rewriting scripts and retraining users. Also it means fighting
a lot of deeloper resistance. Having gone from cvs->tla->baz and now having
to move to something else is quite frustrating. Not to mention having to 
explain all these changes to the boss, "hey, but you said that baz solves our
problems, and is being actively maintained, now you're telling me we have to
switch, again?".

It is going to be bad enough staging a transformation of the backend from
one format to another, and getting everyone to change clients at the same time,
but also having to get everyone to switch development model, and interface
is going to make a switch very difficult.

The tla->baz switch was relatively painless since it didn't require changing
backends, and the command line interface was relatively similar.

>Because I would want the files to be pushed remotely, I probably don't
>want to have that as my only store. As then you have a bunch of latency
>for everything you want to do. (I would even consider trying to figure
>out some way to async the push, so I don't have to wait for it before
>the commit is done).

I don't care too much about the latency, in a team sitting in the one office
setting, the latency to a server isn't really too much of an issue. But
the advantage of having everything stored centrally so all developers can
access it, and so that it is centrally backed up, far outweighs the latency
issue.

>>From my understanding, the only remote branch functionality that bzr
>will have is push (and full read support). You won't be able to merge
>into a remote branch. But bzr supports the property that if you merge
>remote into local, the merged revision can be pushed back to the remote.
>(Right now, bzr would have a hard time writing to the remote working
>tree, most of the code assumes local access. The remote .bzr directory
>is different, as almost all the calls go through the Branch object,
>which can easily be overridden to provide remote access).

I haven't looked at the code since around 0.4, so I guess I need to start
getting the hands dirty again now that baz is deprecated.

Benno