> From: Greg Hudson [mailto:ghudson@MIT.EDU]
>
> On Thu, 2002-12-12 at 16:30, Bill Tutt wrote:
> > I'm certainly interested in any other conceptions of how to support
> > distributed repositories.
>
> For almost any conception of distributed repositories, I can imagine
> handling all of the smarts on the client side, using properties for
data
> like ancestry.
>
Indeed. I definitely concur.
> I'm not saying your way is the wrong way, but I don't think we should
be
> taking baby steps in the direction of a design which exists purely in
a
> few people's heads. I don't even know what problem you're trying to
> solve with your vision; "mirroring and replication of data" sounds
very
> different from the distributed repository functionality people most
> often ask for (which is the ability to perform local checkins of work
> done offline, or local checkins of work on a local branch of a project
> you don't have commit access to).
>
Mirroring and replication of data is very different from the two use
cases you mention since those can be accomplished via ancestry-set
information. What I mean by mirroring and replication is basically the
BitKeeper pull/push/sync kind of model where you pull subsets of the
remote version history into your local repository so more operations
than just commit can work offline. I'm not whole heartedly in favor of
us supporting such an approach. However, replication's upsides do have
some real use cases as well.
For example: offsite workers in India who have abysmally flakey internet
connections.
> In <20021212141542.A1280@answerfriend.com>, mbk wrote:
> >typedef struct
> >{
> > const char *url;
>
> The repository for a URL varies depending on how you access it; you
> might use file:, http:, and svn: to access the same repository. I
think
> we should avoid storing any data in one repository about another
> repository, with the exception of the guid.
>
A user might indeed do this, however I'm going to guess that a
repository has a preferred connection method to that repository. This
field is clearly more useful if you are doing some kind of replication
footwork.
> > const char *name;
> > const char *short_desc;
> > const char *long_desc;
>
> So each repository contains a directory of descriptive information
about
> a bunch of repositories? I don't like that at all.
>
The URI would probably be good enough. These descriptions probably
aren't necessary.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 13 01:25:38 2002