[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Another working copy library

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-01-19 13:25:48 CET

[ 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

This is an archived mail posted to the Subversion Dev mailing list.