> 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 #).
Yes it needs planning. No the problem isn't version numbering. It's unique
I emphasize this because by focusing on numbering we are led astray from
some other solutions, among them cryptographic hashes. The sequence numbers
are purely a human convenience. They are an emergent property rather than an
essential one. That is, the fact that a given checkin becomes version 3 is
because there were two previous checkins. There was no intentionality
involved in the choice of the name "3". Conversely, when we think about
entity names, we focus on intentionality and let the numbering system emerge
as a side effect.
I don't know how to articulate that better, but I have found over many years
that focusing on intentional rather than accidental behavior leads me to
> 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
Deletes and adds are fairly easy to spot, and the tool definitely needs to
be able to find them. Whether it should do so on commit is a question of how
much handholding you want. I don't have an opinion.
Locating an fs rename combined with some other change starts to get pretty
damned hairy, though.
> 3. Have you considered expressing all the file transfers, deltas,
> metadata, etc. in XML?...
I agree that it is desirable to have a canonical expression in XML. That
said, XML isn't a cost-effective storage format and the open source tools
for manipulating XML are still pretty raw unless you are prepared to work in
Java. I've been using XML heavily in another context, and I'ld say they are
"not soup yet" unless you have a compelling requirement to do XML for other
Received on Sat Oct 21 14:36:05 2006