Re: [Gnu-arch-users] "virtual" archives in arch

[Mirian Crzig Lennox]

address@hidden (Charles Duffy) writes:
> On Sat, 2003-12-13 at 14:11, Mirian Crzig Lennox wrote:
>> My idea is to create a virtual archive which speaks "pserver" protocol
>> to a remote CVS server, but supports the interface defined by
>> arch_archive_vtable in libarch/archive.h. [...]
>
> 1> Feasibility. Not all of arch's semantics can be implemented in a CVS
> repository -- atomic commits, for instance -- while keeping the contents
> of the repository something that traditional CVS users still find
> useful;  effectively, to maintain arch's useful semantics, you'd have to
> make arch into another metacvs.

If the CVS repository is not accessible except via the pserver (such
that there is one and only one process which can modify the
repository), then commits are in fact atomic.

That is why I specified "pserver" protocol (which is really "server"
protocol with some lame authentication goo tacked on to the front).

> 2> Performance.  Should you  decide to keep compatibility with
> traditional (non-metacvs-like) layouts, a lot of operations which are
> O(1) in arch suddenly become at least O(n) under your proposition, n
> being the total number of files in the repository.

But the issue there is not how much slower it would be than pure Arch,
the issue is how much slower it would be than pure CVS.  The only
reason someone should even be thinking about doing this is if he were
forced to use CVS, but wanted the comfort of doing so from Arch.  In
that case, one might well consider O(n) (but probably not O(n^2)) to
be a price worth paying.

> I'm sure there are other issues as well, but these are the first two
> that come to mind for my non-guru self.

Thanks for giving it a think-through.  So far, the issues don't seem
particularly damning, but I'll wait and see what others come up with.

cheers,
Mirian