[squeak-dev] Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

Tobias Pape Das.Linux at gmx.de
Thu Jun 19 19:28:51 UTC 2014


On 19.06.2014, at 21:21, Chris Muller <ma.chris.m at gmail.com> wrote:

>>> Why not tell me what you learned so I can learn too?  I really want to
>>> know why the separate spur repository was so bad it has you wanting to
>>> hack version-names so they can act as a string-filter "partition" in
>>> one big slow repository instead of simply using two repositories (two
>>> ecosystems).  I'm not seeing any sanity in that..
>> 
>> OK.
>> 
>> First, making the update scheme handle two repositories is non-trivial.  The
>> code needs rewriting, and that is too complex for me.
> 
> With simply a temporary ecosystem for spur, I don't see why we
> couldn't simply throw it out.  A cron or whatever uses your conversion
> utility to regularly convert/copy new submissions from trunk to spur.
> A clean separation-along-the-physical-seams rather than making
> domain-soup like we're doing.
> 
>> Second, the non-branch scheme is at best confusing or at worst clashes in
>> places like the package cache.
> 
> Yes, I acknowledge that loading stuff from the package-cache would
> require a few extra clicks to identify what you wanted to load..  I
> guess dedicated local file directory repositories (<-- plurality
> important) would be the "normal" way to work offline?
> 
>> Third, the branch scheme does all we need already, because it was my
>> misunderstanding that a branch name would prevent me removing the branch
>> name once we're ready to switch to spur.  That's not the case.  The ancestry
>> apparently doesn't include the branch name.
> 
> Doesn't it?  See below the ancestry of VMMaker, the transition from
> the mainline to the "oscog" branch (54-55) followed by the next
> descendant (55-56).  Including the branched-name in the ancestry
> actually makes sense to me; since that's the only way a FileBased
> repository would be able to efficiently find the ancestral record..
> 
> "54-->55 transition into oscog branch."
> Name: VMMaker.oscog-eem.55
> Author: eem
> Time: 26 April 2011, 11:47:29.937 am
> UUID: 315353fc-7f75-4b5b-8a43-3a636cb1aa0b
> Ancestors: VMMaker-oscog.54
> 
> "55-->56 first branched node is ancestor of the next descendant."
> Name: VMMaker.oscog-eem.56
> Author: eem
> Time: 26 April 2011, 5:49:36.229 pm
> UUID: fbf17bd2-ddbc-488f-b70d-3b9ba8906430
> Ancestors: VMMaker.oscog-eem.55
> 
> I'm sure you can still remove the branch-name at some point, but the
> record of it having gone through that branch will always be in the
> ancestry for posterity.
> 
> It seems that I'm the only one who thinks MC branches are not worth
> their costs.  Our tools have bugs and limitations w.r.t. branch
> support (like the selection-issue you mentioned in the meeting).  That
> means we can either put our energy into fixing them, or put energy
> into transitioning to something simpler (or, of course, do nothing,
> which means we live with the bugs).  I, of course, prefer to simplify,
> but since we are already this deep into them, I guess we'll just have
> to manage it..

Chris, there is no way around having _some_ kind of branching mechanism 
that supports multiple branches within the same repository. There is no
“simpler” there.
  Without that we would fall years (decades?) behind other VCS, even 
SVN or CVS, and _I_ am not willing to swallow that. Sorry, but I know
no way around this.

Best
	-Tobias





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1625 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140619/273fa63c/signature.pgp


More information about the Squeak-dev mailing list