Nuutti Kotivuori <naked@iki.fi>
> So - what can you contribute to subversion as it is _today_, so that
> it can still keep operating like it is today, even if the change is
> for tomorrow?
Exactly! Thanks for saying it so well, Nuutti.
And I think that's enough meta-discussion for now... So back to the
technical questions David Lowe raised:
"LOWE,DAVID (HP-Vancouver,ex1)" <dave.lowe@hp.com> writes:
> On Thursday Jack decides he needs Jill's Wednesday changeset and applies it
> to his file. My "order independent changeset" would give Jack these file
> contents.
>
> main()
> {
> Func1();
> Func2();
> Func3();
> WednesdaysFunc(); /* Wednesday's changeset */
> Func4();
> JacksFunc(); /* Jack's changeset */
> Func5();
> }
>
> Can I get that from subversion?
As others have pointed out, yes, just run 'svn merge'.
But, some problems we still need to solve:
1. The merge history should be recorded; that is, the system needs to
be somehow aware that this particular changeset was applied to this
file. This is something we've been discussing a lot anyway, I know
Branko among others is itching for it (I am too!).
IMHO, if we had to choose just one changeset-supporting improvement
to start on right away, this would be it. It's almost the exact
middle step between a CVS-like system and a BitKeeper-like system.
2. The example above is nicely formulated to avoid questions of change
interdependence. Obviously, we'll have to handle harder cases as
well. (I must admit I didn't really understand the answers posted
so far about this problem, but I need to go back and read them
again). David, have you read this document:
http://svn.collab.net/repos/svn/trunk/www/variance-adjusted-patching.html
? It's written from a patch/diff point of view, but I believe the
principles are applicable to arbitrary byte patterns. It's my
naive attempt at addressing the issue of overlapping changes; I
doubt any of the techniques are news to you, but perhaps there's
something useful in there. All theory right now; Subversion
doesn't yet have any code to do this.
I think (2) is important, but gets easier to conceptualize after
we've solved (1).
> It also needs the ability to marshal changesets between repositories.
Yup. Ouch :-). Related to (1). If repositories have UUIDs, for
example, then the merge histoy should record it...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 11 17:16:44 2002