[ snip ]
> So, what am I trying to say? I am positive to this idea in general, but
> I think we need to consider it a part of a movement towards 2.0.
> I think we should create a completely new API and start using it in our
> code and create a wrapper implementing the new API in terms of the existing
> libsvn_wc API.
I'd like to add that I agree that a new working copy model would allow
us to start a migration towards 2.0. Personally, I'd like to make
'call it 2.0 and ditch the old stuff' a separate decision from whether
or not to create a completely new WC access API: If/when we make
mistakes in the design, but release the first version(s) within the
1.0 cycle, we can ditch the mistakes when finally moving to 2.0 with a
solidified, tested and proven new WC API.
> > I'll start drawing up a more detailed design tonight, to flesh out the
> > general ideas.
> >
> Cool! Looking forward to reading it.
So am I. I'd like to point out that there should be a functional
discussion before we actually have the design discussion though: The
current library happens to do some things in ways which just happened
to be implemented in a certain way or inherited from the editor API.
I'm referring to the way tree changes are treated and especially the
way updates and merges interact with local tree changes: Should an
update of a locally replaced file merge the changes, or is it really a
different object and should the tree change itself be marked as a
'C'onflict? If we have conflicting tree changes, how do we want the
library to act upon them?
In other words, I think it's great to work on a new working copy
library, but I think we don't really have fully defined semantics for
a working copy library just yet.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 19 13:26:14 2007