On 16.06.2014, at 21:21, Chris Muller <asqueaker at gmail.com> wrote:

> The practical reason I do not wish to increase our use of branches is
> that forces a dependency on MCFileBasedRepository's.  Recall all that
> work in 2011(?) to clean up and unify the MCRepository API and reify
> MCVersionName so we could support all the other Repository types and
> begin to introduce more and better tools?

Sure. This work made explicit the conventions that were mostly implicit or only in the UI before.

> Then, in 2012, some code to support "branches" that was put into
> FileBasedRepository like this:
> 
>    (packageName includes: $.) ifTrue: [ "do this" ] ifFalse: [ "do that" ].

Branches were supported way before that, just in a manual way. The only reason to have "versionNamesForPackageNamed:" was so the updater could infer which versions belong to a package. Before, a *human* would choose a version and load/merge it, and only at that point would the package name become known (it is stored inside an mcz). Actually MC places no restriction on version names at all, they don't even have to contain the package name. But our update stream relies on naming conventions, so we had to codify them. And that's why it also needs to understand the convention about branches. This is only used for automatic updating of configurations - an operation that did not exist at the inception of MC.

> If want to be able to use Monticello with any type of MCRepository, we
> need to be conservative about the demands we place on our uses of
> abstract MCRepository.  Operating strictly within the API declared
> there will enable any repository which implements just that API (about
> 8 methods) to be supported.  Making deeper committments to
> FileBased-specific features will further chain us to solely those
> types.

This has nothing to do with files. Strictly with preserving the version name (which any MC repo surely does). And some additional support is needed for automatic update streams, for the reasons I mentioned above.

>> There is nothing to "adopt". This is how MC was designed to handle branches.
> 
> All of MC's internal domain functions:  the change reporting, history,
> comparing and merging functions; all operate from the
> internally-maintained 'ancestry', not any version name that was
> entered by the user.
> 
> I think you're referring to the convenience of grouping versions of
> the same branch together in the Repository inspector UI's list of
> versions, is that right?  I'd bet that use-case could be solved
> another way -- such as the History button of the WorkingCopy's to
> simply look at the ancestry and then select the desired version from
> the repository list..
> 
> MC's model is fairly beautiful and I think we should stick with the
> truth and the beauty.  Multi-use fields are not beautiful, and it's
> not clear that MC was "designed to handle branches" because it already
> maintains its own first-class Ancestry but nothing first-class about
> branches, and no support for them outside of FileBased, and no mention
> of them anywhere else in all of MC.

Branches are simply implicit, always have been, by file naming convention. Only when we chose to base our update stream on a FileBasedRepo we needed to add some recognition of this pattern so it would work automatically. Nothing more.

This is analogous to how other CMS handle that. E.g. in Subversion a branch is just a copy of the tree to a directory named "branches" in the same repository. It's just a naming convention. Same here. We don't have a hierarchy in our repos, so we make the version name carry that information. Works fine. I'm not entirely sure what the big deal is.

- Bert -



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140616/b179b666/smime.bin