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.
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).
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.
> 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.
> const char *privkey;
What would this be used for, and (as Branko tried to ask) why would a
repository know any private key other than its own?
---------------------------------------------------------------------
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:03:12 2002