Recommended backup procedure and preserving my data...

[John Szakmeister]

On Fri, Oct 16, 2009 at 10:27 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
[snip]
> bzr-svn, for example, can produce ghosts. Namely doing:
>
> bzr co $UPSTREAM upstream
> bzr branch upstream local
> cd local
> commit commit commit
> cd ../upstream
> bzr merge ../local
> bzr commit -m "Merge my changes back to svn."
>
> At this point, in *SVN* it records that this revision was a merge, but
> svn does not have the "local" commits. It has a pointer to a revision,
> but none of the data for that revision.
>
> If someone else independently then does:
>
> bzr co $UPSTREAM upstream
>
> They have ghosts until they somehow get direct access to your "local"
> branch.

Thank you for the *great* example.

[snip]
> 'limit on throughput'? Two people cannot update a branch at the same
> time (we create a lock while you are pushing your changes.)
> However, the repository design is such that changes are pushed to
> 'upload', renamed into place and then we only need to take out a
> physical lock for the brief seconds that we update the 'pack-names'
> file. (take a lock, read the file, compare it with our known info,
> update accordingly, write it out, unlock)
>
> So by design, you can have a lot of concurrent writers to the same
> repository. Potentially they can write redundant data, but we will
> filter that out during autopack, etc.

Good to know.  I knew there was a branch level lock, and was hoping
that didn't translate to the repository side.  You guys are smart, so
I figured it was okay, but it's great to see the details.  Thank you
for taking the time to explain it.
[snip]
> So in summary, we've designed it to be fairly insulated to concurrent
> readers and writers. It may not be perfect, but it is pretty darn good.
>
> Oh, and I should note that if you are using smart requests, the
> 'restart' is done server-side. I've had someone run "bzr pack" on my
> repository while fetching and never noticed a hiccup in the data stream.

Awesome.

>
> ...
>>
>> I guess I still have the issue mentioned here though:
>>     http://doc.bazaar-vcs.org/latest/en/user-guide/http_smart_server.html#pushing-over-bzr-http
>>
>> That is, I need to do something so that I can segregate write access
>> and read access.
>
> Do you want to allow anonymous access? Or you are just saying that you
> want some people at a given branch to have readonly access, and others
> to have write access.

The latter.  It's actually 3 levels: some folks can't see anything
related to the project, many folks will have only read access, and a
select few have write access.

> I don't know if that is easy to do with Apache's proxying. (Though you
> could have a readonly smart server running and a read-write one running,
> and Apache's acls would redirect the requests to the server which gives
> the appropriate response.)

Interesting idea.

> You might also want to look at "contrib/bzr_access" which has a single
> ssh user, and controls ACLs based on the ssh key given. It also gives a
> restricted shell. (So users can't login directly and do anything, they
> can only spawn 'bzr' and talk with it.)

Right.  I set this up for a few of us.  It's just a little more
configuration for the user than I would like, since they need to edit
the .ssh/config (or the Windows equivalent) to assign the username for
that host.

> There is also some work that has been done for ACLTransport, but I don't
> think that is complete.

I'll keep my eye on that too.  For now, I'm going to look at using the
smart-server via HTTP.  Thanks again for your replies.  They were very
informative.

-John