Hi all,
The design doc looks great! All the improvements over cvs are
exciting :) I have a couple of comments:
1. I completely agree with Zack's argument for working repositories
(6/3); I think the heirarchical model elegantly combines and solves
the working repository and mirroring issues, and nicely treats a
working repository as a branch. Among other benefits, Zack's model
allows you to keep your working repository on a server somewhere. I
often work on the same code base from multiple machines, e.g. home
vs. office, but don't want to have to commit buggy code for others to
see, just as a convenient means of copying it from one machine to
another. I understand why working repos are scheduled for
"immediately following v1.0", but I think some planning is needed
now, e.g. to account for a distributed file id/version numbering
system. The hierarchical model requires either a) a way of doing
distributed unique version numbers, or b) associating multiple
version numbers with each file (e.g. the local version # vs. the
upstream version #).
2. (low priority) The svn client should be able to deal with file
moves/renames/deletes that are done directly in the filesystem, not
through the client. E.g. if I delete a file, and then commit or
update, svn should warn me, and perhaps even ask whether I intended
to delete the file from the repository as well or if I'd like to
update it. If the svn client finds both deleted files and added
files, it could try to match them up to see if they're actually just
renamings.
3. Have you considered expressing all the file transfers, deltas,
metadata, etc. in XML? That carries with it a whole slew of
benefits, I think, at the expense of (perhaps) a bit of extra storage
and transfer overhead.
a) Straightforward, widely understood syntax will facilitate
greater developer participation, as well as extensibility &
interoperability of the product;
b) It's easy to use existing libraries for parsing & various
processing;
c) tree structure lends itself well to this application, e.g.
the delta format maps directly (though it expands a bit in size);
d) instant web interface via XSL;
e) straightforward import/export (section 7.2.8).
-David
________________________________________________________________________
David Soergel .oooO Oooo. "Music and Living----"
123 Forest View ( ) ( ) "The same thing," said Pooh.
Woodside, CA 94062 \ ( ) / lorax@lorax.org
(650) 303-5324 \_) (_/ http://www.lorax.org
________________________________________________________________________
Received on Sat Oct 21 14:36:05 2006