RE: [Gnu-arch-users] Re: may I pick your brains?

[Parker, Ron]

> From: Parker, Ron [mailto:address@hidden

> > From: Miles Bader [mailto:address@hidden
> 
> >   o Easy distributed development, especially `distributed 
> > branching' --
> >     you can make a branch off of _someone else's_ archive, even you
> >     only have read access, and doing so is very cheap.  Merging back
> >     and forth is easy once you've done this.

I thought of another spin on this, while grabbing lunch, that should be
immediately understandable by managers, network storage specialists and DBAs
alike.

"Simple, safe and efficient replication and synchronization."

If you view mirrors, branches and libraries as replicating an archive or
portion of an archive, then merging or archive-mirror is little more than
the synchronization of changes between replicated archives.  

Where I work this would be a big deal.  Some of our development has been
outsourced to a company in Hungary.  The issue is that we use SourceSafe and
even using SourceOffsite to allow them access to our repository things are
horridly slow even though they have a broadband connection.  SourceOffsite
purports to reduce what needs to travel over the wire by a factor of 12x.
When your dealing with a repository of over 1GiB this is still a lot of
network traffic.  As you can imagine, their check ins take hours.

The result of this is that we tend to get their code in big drops, normally
only as a contract milestone approaches.  Because of the slowness of the
connection, they pull our source and use CVS locally.  Then when they are
ready to do a check in, they push the whole thing back to us.  This
frequently results in changes being overwritten here and someone having to
repair our Workspace files (MS Visual Studio "makefiles") before anyone here
is safe to do a check out and build.

If however our friends in Hungary could maintain a mirror or a library, they
could resync their changes with ours more frequently and at a finer
granularity avoiding many of the problems we see.  This also would address
the efficiency issue, since only logs and patches would really need to be
sent back to us and as Tom is fond of pointing out, with proper caching
arch's bandwidth usage is near optimal.

I know I'm glossing over/aliasing the finer details, but hopefully there's
enough here for someone to distill it into something resembling the truth.