[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [subversion-dev] Working repos; move/delete issues; XML

From: Jonathan S. Shapiro <shap_at_eros-os.org>
Date: 2000-06-15 14:29:27 CEST

> 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
entity names.

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
better designs.

> 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.

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.