In an incredibly long, mixed-topic post, Tom Lord wrote:
>* Separating V.A.P. from Merge History
>
> Sander's proposal talks about v.a.p. being the merge mechanism,
> but the proposal is really about merge history.
>
> These are separate concerns. There are many merge algorithms,
> v.a.p. being just one. Merge history is relevant to many of those
> algorithms.
>
> It's a useful touchstone to make sure that the proposed history
> mechanism is sufficient for v.a.p. -- but a mistake to think that
> v.a.p. is the only algorithm it should support.
>
> Rather than v.a.p. alone -- it would be useful to have a list of
> touchstones by which to judge history mechanisms. These should
> include alternative merge algorithms, sure -- but also uses of merge
> history in situations where repository access is not assured,
>
That part is served quite well with Sander's proposal, because
properties (and thus the merge history) are represented in the working copy.
> and
> generation and application of changesets in situations where
> repository access is not assured.
>
>
Both generation and application of changesets are possible. Even a merge
is possible without repository access, assuming you have both branches
checked out.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 15 02:10:17 2003