Avi Bryant wrote:
> On Sunday, September 21, 2003, at 07:33 PM, Colin Putney wrote:
> 
>> It does go beyond optimization, though. Right now, VersionInfo is only 
>> ever part of a Version. Occassionly we'll grab a version's info, 
>> examine it and then throw it away. I'm talking about making 
>> VersionInfo more of a first class entity, one that might be stored or 
>> transmitted on it's own.
> 
> 
> <snip>
> 
>> To get back to the problem at hand, I'd much rather have a 
>> user-definable search order for repositories than a url pointing back 
>> to the snapshot. More generally, I'd like to have Monticello work with 
>> naked VersionInfo much of the time, and retrieve or reconstruct full 
>> Versions only when necessary.
> 
> 
> You make good points here.  If we're going to be moving in that 
> direction, I would propose the following entities:
> 
> VersionReference - contains the actual name and UUID of the version
> VersionHistory - a tree of version references.  Log, date, etc, should 
> maybe be in these nodes as well.
> VersionInfo - contains a VersionHistory and a Package.
> Version - contains a VersionInfo and a Snapshot.
> 
> There are two motivations here.  One is to bring Package into 
> VersionInfo, which makes VersionInfo objects more useful on their own - 
> otherwise, you can't group/filter by package which is an obvious thing 
> for a UI to want to do.
> 
> The other is to introduce a lightweight object for when really all you 
> want to do is refer to a version by ID, and you don't need all the 
> ancestry - which is true in many of the places that we currently use 
> VersionInfo.
> 
> Anyway, with some reasonable way of representing VersionInfo on its own, 
> I can definitely picture having a somewhat centralized "feed" of 
> VersionInfos that you would subscribe to (ie, that would automatically 
> download itself into your local cache and build pretty ancestry trees, 
> etc), combined with the distributed searching through repositories that 
> we currently have for actually getting the snapshots.


This all sounds quite a bit better to me.

I wanted to raise my other concern that I thought of last week:  having 
all the ancestry information duplicated inside every version means 
there's absolutely no way I could ever go in and "fix" ancestry 
information after the fact.  The benefits to this approach almost 
certainly hugely outweight this problem.  This came up in a repository 
where the first version committed was a released version of an existing 
package with some modifications (can't remember whether it was seaside 
or what).  When I discovered this, I was annoyed that there was no 
version as an ancestor that was identical to the last version in the 
previous source code management system.  But I realized there was no 
possible way to find every version info on the planet and correct them 
to contain the new ancestry.

Don't really see an obvious solution but thought I'd mention it so 
others were aware of it as well.  I wonder whether this is another 
artifact of my CVS-mindset?  Does everyone else think being able to 
tweak ancestry like that is unnecessary or just a useful tradeoff?

Julian