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?
...
> +Would-be-very-nice-to-have's
> +============================
...
> + * Ending up with an implementation which can use current WCs
...without conversion?
> 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.
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.
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.
...
> +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? :)
...
> + - 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.
...
> +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.
- application/pgp-signature attachment: stored
Received on 2008-03-16 22:14:51 CET