David Soergel <firstname.lastname@example.org> writes:
> 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
> 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
> 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).
Have thought about it; haven't concluded yet (since don't have to --
we're not at that stage yet). Yes, there are advantages &
disadvantages. If we sound undecided, that's because we are. :-)
Received on Sat Oct 21 14:36:05 2006