I started out writing a long reply to this email, and then I realized it
just wasn't worth it. If you don't know it, I'm not working on
Subversion full time either. I have a full time programming job that has
nothing to do with version control and I'm married. I'm just happy that
I've been able to contribute as much as I have been to Subversion. The
kinds of operations/situations that Subversion's data model handles are
very complex. I wish I had more time to spend on such issues, but sadly
there's only one of me to schedule my free time with as opposed to 5+
clones of me each doing a subset of the total amount of interesting
things I'd like to work on. I'm glad in the past you've had time to work
on arch so much. It's a shame you didn't give the Subversion folks a
chance, since the fundamental data model has changed substantially since
its initial conception.
Greg Hudson commented on how Subversion is using basic project
management to get 1.0 out the door, so I'm not going to bother
commenting on that.
A common patch set format would indeed be nice, but honestly it isn't
going to be on the top of anybody's plate for awhile yet. It seems more
likely that such a thing would be much more likely when Subversion
decides to take on the chore of moving it's data model to one that takes
distribution into account. When Subversion is ready for such a thing, it
will need some kind of patch set format for replicating changes. This
will include handling copies correctly.
Patch set formats in the context of version control systems aren't just
about merging changes into someone's local working copy, it's also about
specifying some sane kind of version related merge semantic. (ala the
merge of a new directory from one branch to another should be a copy
with history instead of just an add) Thinking about how to handle the
multiple branch merge rename issue would probably be a good thing as
well.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 11 02:45:24 2002