[NIT] Managing repositories in MC

Colin Putney cputney at wiresong.ca
Mon Sep 22 06:49:05 UTC 2003


On Sunday, September 21, 2003, at 10:33 PM, Julian Fitzell wrote:

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

Good point.

I think one of the side effects of letting VersionInfo live independent 
of it's Version is that won't have to be duplicated quite so much. I 
imagine Monticello could build a single VersionHistory with information 
gathered from several sources. So that would present a convenient, 
central place to make corrections. (Sure, you'd still have a "central" 
tree per image or maybe per MC user, but that's still much less 
duplication than per Version.)

Also, if we end up with a VersionInfo "feed," we could use it to issue 
updated VersionInfo for a particular VersionReference. That is, the 
semantic of a VersionInfo appearing in the feed could be "make your 
local VersionInfo for this UUID match this data," which might require 
creating it in the first place.

Colin



More information about the Squeak-dev mailing list