On Mon, Jul 23, 2018 at 05:08:57PM +0200, Nicolas Cellier wrote:
> 
> On 23 Jul 2018, at 09:51, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > I would be happy just to see UpdateStreamDownloader get a good class comment
> > that explains what it is, and that clarifies the difference between our current
> > Montecello based update stream and the older change set based stream.
> 
> By principle of encapsulation, a comment should not tell about the
> implementation of another class.
> So if we need a comparison, it should lie somewhere else.

Fair enough. But I would still be happy if UpdateStreamDownloader could
have a good class comment. Oops, I fear that I have just given myself an
assignment ;-)


> 
> An update stream is not a version control system. The update stream that we
> > use today happens to be built on top of Montecello, but if we ever wanted
> > to decouple the update stream from the version control system (for example,
> > if someone wanted to use git for version control), then it might be
> > important
> > to have a simple change set based mechanism that works independent of the
> > version control systems.
> 
> But if the update stream does not refer to the VCS, then we get an image
> out of sync with the VCS which is an undesirable property.
> If we would switch to git or whatever, we should arrange to keep the link
> between image and git repository.
> 

Fully agree. I was thinking of a scenario in which the update stream is
generated by, and is not a replacement for, the VCS.

I think that this has been done in the past with our MC based update
stream. Maybe Andreas did it? Or Edgar? Sorry I do not remember.

For any VCS, including Monticello, if it is possible to implement an
update stream with that VCS, then it must also be possible for an image
that is being updated to keep track of its update history in the form of
a list of change sets. And it should be possible for that list of change
sets to be re-applied to another image to achieve that same end result.

Dave