On Tue, 2004-10-05 at 01:13, Rob Weir wrote:
> Eric, how do you plan to implement a distributed version control without
> file-ids[0]? Or do you think every repository should have all it's
> history, ala BK?
> [0]: this was more or less the point of the discussions on the changeset
> list last year.
Yeah, and I expect we'll hit the same dead end; we're not currently
prepared to reconceptualize Subversion in arch terms in order to have
arch-style distributed version control.
But I do have one new argument against file IDs: in a world where some
of development history is supposed to remain hidden from some parties,
file IDs leak information.
To use an example not too far from the real world, suppose you are a
fab, and you work with several fiercly competetive chip design companies
within the same repository, which has a "public" area (accessible to
everyone) and private areas which are accessible by the fab staff and a
particular partner.
Now, suppose one of the partners, company A, takes a public chip design,
does some work on it within the private area, and produces another chip
design for the public area. To the fab staff and company A's staff, the
history of the files for this chip design should look like:
second public incarnation <-- private <-- first public incarnation
To company B (which isn't even supposed to be privy to who the fab's
other partners are), the history of the second public incarnation should
hit a brick wall at the first arrow. But file IDs will allow company B
to deduce that these files were eventually derived from the first public
incarnation, which may be information useful in competition ("it seems
someone is deriving memory chip designs from clock chip designs").
Does this mean public file IDs are an invalid idea for version control
software? Not necessarily; arch has (as I understand it) little
interest in this kind of privilege separation, so there's no issue
there. Can we have good distributed version control with good smart
merge support without file IDs? Can copy-tracking be meaningful in a
distributed context? I don't really know; distributed version control
and smart merging aren't really my areas of interest. (I know svk has
implemented these things without file IDs, but I don't know how it
works.) I'm just throwing this out there. It may be that Subversion
eventually decides it is more interested in arch-style distributed
version control than it is in this kind of privilege separation.
I'm going to note this message in issue #1525 ('Use new "entity ID"
notion instead of "committed rev"') because the proposed "entity ID"
concept is a kind of public file ID.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 7 00:15:21 2004