Re: networking repositories

Fine. I'll bite.

   A quick list of problems with traditional patches (i.e. diff(1) output)
     * metadata (properties)
     * log messages
     * binary files
     * deletion of directories
     * addition of empty files
     * svn cp

arch takes care of all of those for you plus much, much more. It has
been proposed and rejected to integrate these features of arch with
svn anytime soon.

     * platform-dependent line-endings (ie. with svn:eol-style=native)

I don't know much about this area, being rather focused on unix.
There is ongoing discussion on the arch-users mailing list about
finalizing our changeset format and semantics, and if you have
an informed perspective on this issue, I encourage you to participate.

See: www.fifthvisiion.net/Arch to find the mailing list.

   Thus you'll need to add metadata in the output, and have the import
   program correctly interpret this. (but it'd be great!)

It is great. A distributed system that handles these things well is a
joy to use.

We treat "metadata" as "just more to the source tree", btw. -- a
successful approach that draws into question svn's use of
`properties'. Ordinary whole-tree patching is sufficient to handle
those things people often call "meta-data".

`arch' doesn't _need_ the svn storage manager but it would arguably
be a nice addition, if the details could be reconciled, and the focus
of svn development slightly shifted to storage mgt.

It's instructive to look at the engineering practices going into the
linux 2.6 effort to begin to understand why distributed revision
control is critical, these days. In reading the related materials,
keep an eye out for phrases like "nicely broken out change/patch
sets".

-- Your friendly svn project manager dissenter, who notes a decided
absense of solidarity displayed by svn's core, especially corporate,
maintainers, and adds this to the long list of reasons to consider
becoming a free software union organizer,

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 27 22:38:47 2002