Kean Johnston wrote:
> "Design a system that provides all the current functionality of
> the duplicated-contents text-base approach in a way that
> minimalizes the actual duplication of data, or, ideally,
> eliminates it."
[...]
> Anyway ... thats my idea. Let the flames begin ... I have my
> asbestos suit on :)
I am going to be mean and ignore most of the points you had in your
message. You can imagine the trivial arguments such as "get a better
filesystem", "fix your tools", "use 'svn export' for builds, not a
working copy" and so on to everything else. And for the 'svn edit' use
cases I'd say that it's better not to even mention advisory locks and
developer communication in this context. Let's concentrate on 'svn
edit' behaviour with regard to this feature.
In my opinion, the main point that stands on it's own there is indeed
"detection of changes without a tree-walk". And this is a tough nut to
crack. It will require reworking the entries parsing logic, perhaps
adding new fields there - it will also either require settling to a
model where every directory still has to be traversed or bubbling up
changes to all parent working copies. Perhaps even new files in the
working copy that simply signify a "not-modified" situation.
And this really doesn't sound trivial to get done. Elimination of
text-bases is a nice thing - but the elimination of the need to
traverse is what makes it a killer feature. I hope you can come up
with a reasonable solution to this.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 17 11:05:41 2002