On Sun, Mar 16, 2008 at 10:15 PM, Daniel L. Rall <dlr_at_finemaltcoding.com> wrote:
> On Sat, 15 Mar 2008, dionisos_at_tigris.org wrote:
> ...
>
> > --- trunk/notes/wc-ng-design Sat Mar 15 15:19:21 2008 (r29931)
> > +++ trunk/notes/wc-ng-design Sat Mar 15 16:09:52 2008 (r29932)
> ...
>
> > @@ -110,6 +111,8 @@ Requirements
> > - central vs local metadata storage
> > - Last modified timestamp behaviours
> > - .svn-less working copy subtrees
> > + - different file-changed detection schemes
> > + (e.g. full tree scan as in wc-1.0 as well as 'p4 edit')
>
> I like this idea. Were you thinking that this would key off of WC-specific
> changelists (sounds good to me)? If so, would we need to lift the "no
> directories" restriction for changelist contents?
Heh. No idea actually, but I think it would be a good solution. I was
merely adding the result of a chat with epg and my resulting thoughts
here.
> > +Would-be-very-nice-to-have's
> > +============================
> ...
>
> > + * Ending up with an implementation which can use current WCs
>
> ...without conversion?
That was the intended statement, yes. (I added a note to that extent.)
> > Possible solutions
> > ==================
> > @@ -260,13 +278,16 @@ regarding the exact tree which is being
> > Most operations are I/O bound and have CPU to spare. Consider the virtue
> > of compressed text bases in order to reduce the amount of I/O required.
>
> I'd like to see optional text bases taken into consideration as a "nice to
> have", more to keep them on our radar than to try and get them implemented
> as part of wc-ng.
Ok. I explicitly added that, but later on in the document, there's a
specific storage depot named 'non-local' with which I meant to say
'retrieve from repository'.
> Of even more interest to me would be to change the storage of text and prop
> bases entirely, such that this read-only content could potentially be stored
> in a single location and shared across working copies. The content itself
> would be keyed by hash (e.g. MD5 or SHA-1), and potentially some additional
> data to help differentiate it in case of (the rare possibility of) collision.
> In this scenario, we'd need a facility to evict unused/old content from the
> cache.
I added a note to 'central depot' to the effect of the above, without
the details as we're still on a much higher level of description.
> For any project that I'm serious about, I typically have numerous Subversion
> working copies; this feature would go a long way towards making updates fast
> and significantly reducing disk usage, making extra working copies cheaper.
Since most of my projects are too small to care about this, I hadn't
thought about it, but I like it and it nicely extends the 'store in wc
root' mechanism where I already figured files may share text base/prop
base if they are copies of each other.
> > +Transactional updates
> > +---------------------
> > +
> > +.. where 'update' is meant as 'user command', not 'svn update' per se.
> > +
> > +When applied to files, this can be summarized as:
> > +
> > + * Receive transformations (update, delete, add) from
> > + the server,
> > +
>
> ...and? :)
Well, the commit said 'store todays work' :-) I've got to finish that
bit, indeed.
> > + - tree transformation (required for update/switch/merge updating
> > + BASE, WORKING and ACTUAL), meaning all of tree changes, file
> > + changes and metadata changes
>
> This sounds like it's quite relevant to Stephan Sperling's work.
Absolutely. I have already approached him for comments, but as of this
week he'll be returning to tree conflicts full time, so he expected to
be delivering comments and additions later this week.
> > +Justification for the large number of modules, with a modest number
> > +of different APIs is that the problem is really quite complex as shown
> > +earlier in this document.
>
> Sounds good! I'd like to see clear descriptions of each WC module maintained,
> preferably with an overview in a single place (as you have above), with some
> additional information regarding relationships between'em.
Exactly. My intention is to describe in a next step the scope of each
of these modules in order to see how they interconnect as well as
having a high level overview of whether we could write something along
the lines of wc-1.0 with what I wrote down until now.
If there are parts missing, they either belong in "Public interface"
and can be implemented on top of what modules are intended for
implementation, or we might be missing modules.
How does that approach sound to you?
I haven't spit out a completely done document like DannyB for
merge-tracking for 2 reasons: I can't create it all in one run because
of time restrictions, nor do I actually have all this figured out
[meaning that my thoughts need to materialize while I write].
Any additions/comments you might have are very welcome ofcourse!
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-16 23:03:44 CET