Seaside 2.7a1 versions 169

>
>
>
>
> Hi all,
>
>
>
> There are two version of Seaside2.7a1-nnn.169
>
>
>
> The pmm and mb.
>
>
>
> Could we reconcile and merge the two versions?  Having two versions with the
> same version number wreaks havoc with Monticello Configurations.

> Thanks,
>
>
>
> Ron Teitelbaum
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>

>
> 2007/2/11, Ron Teitelbaum <[hidden email]>:
> > Hi all,
> > There are two version of Seaside2.7a1-nnn.169
> >
> > The pmm and mb.
> > Could we reconcile and merge the two versions?  Having two versions with
> the
> > same version number wreaks havoc with Monticello Configurations.
>
> Not to my experience since MCC takes the author initials into account.
> Later versions even use the UUID so even having two different versions
> with exactly the same filename works fine.
>

> Ron
>
> > From: Philippe Marschall
> > Sent: Sunday, February 11, 2007 12:01 PM
>
> >
> > 2007/2/11, Ron Teitelbaum <[hidden email]>:
> > > Hi all,
> > > There are two version of Seaside2.7a1-nnn.169
> > >
> > > The pmm and mb.
> > > Could we reconcile and merge the two versions?  Having two versions with
> > the
> > > same version number wreaks havoc with Monticello Configurations.
> >
> > Not to my experience since MCC takes the author initials into account.
> > Later versions even use the UUID so even having two different versions
> > with exactly the same filename works fine.
> >
>
>
>

> 2007/2/12, Ron Teitelbaum <[hidden email]>:
>> Philippe,
>>
>> Actually no.  If you update from repositories, which my system does
>> automatically you will see that it changes back and forth from  
>> each version
>> of 169.
> [...]
> Monticello is not CVS, it does not work like CVS, there is no concept
> of CVS HEAD. The version numbers in the MCZ files are not the same as
> CVS revisions. They are merely a way on making sure the filenames are
> unique. They have _NO_ semantics (which is why you are free to choose
> anything).

> 2007/2/11, Ron Teitelbaum <[hidden email]>:
> > Hi all,
> > There are two version of Seaside2.7a1-nnn.169
> > The pmm and mb.
> > Could we reconcile and merge the two versions?  Having two versions with the
> > same version number wreaks havoc with Monticello Configurations.
>
> Not to my experience since MCC takes the author initials into account.
> Later versions even use the UUID so even having two different versions
> with exactly the same filename works fine.

> On 2/11/07, Philippe Marschall <[hidden email]> wrote:
> > 2007/2/11, Ron Teitelbaum <[hidden email]>:
> > > Hi all,
> > > There are two version of Seaside2.7a1-nnn.169
> > > The pmm and mb.
> > > Could we reconcile and merge the two versions?  Having two versions with the
> > > same version number wreaks havoc with Monticello Configurations.
> >
> > Not to my experience since MCC takes the author initials into account.
> > Later versions even use the UUID so even having two different versions
> > with exactly the same filename works fine.
>
> Just as a side note, I based the actual Dolphin port on 2.7a1-mb.169.

> Regards,
>
> --
> Esteban A. Maringolo
> http://dolphinseaside.blogspot.com
> [hidden email]
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> From: Philippe Marschall
> Sent: Monday, February 12, 2007 4:40 AM
>
> 2007/2/12, Ron Teitelbaum <[hidden email]>:
> > Philippe,
> >
> > Actually no.  If you update from repositories, which my system does
> > automatically you will see that it changes back and forth from each
> version
> > of 169.
>
> Ah, you are talking about that functionality. That never worked
> anyway. Even if it worked it would still be a bad idea to use it. We
> don't write change logs for fun. Sometimes we do breaking changes,
> sometimes you will have to change your code, sometimes we do
> experimental versions (with comments like 'do not load') people will
> still load it and complain when it does as advertised.
>
> Monticello is not CVS, it does not work like CVS, there is no concept
> of CVS HEAD. The version numbers in the MCZ files are not the same as
> CVS revisions. They are merely a way on making sure the filenames are
> unique. They have _NO_ semantics (which is why you are free to choose
> anything). The semantics are all defined by the metainformation file
> and not the filename. Filename hackery is not the correct way to
> extend Monticello, it doesn't work and only leads to more problems as
> can be seen with Chronos. The right way is add more metainformation to
> a file.
>
> So what is the latest version of a Monticello Package anyway? It is
> the merge of all the leaves on the ancestory graph in all the
> repositories (yes all, Monticello is distributed), not the version
> with the biggest integer in the filename.
>
> > This means that I update every time my system loads.  It also means
> > that I have no idea which version is considered the current one.  It's
> > better if we do not release two versions with the same number, unless we
> are
> > intending to permanently fork in which case I would recommend using a
> dot
> > version 169.01 or a new name for the fork.
>
> > Since that is not the case could
> > we reconcile and release a new version?
>
> When they are ready to be merged, they will be merged. It is not the
> first time we have versions with the same version numbers and it will
> not be the last. Monticello does not force you to synch before
> committing, making every commit a branch, and it works very good this
> way.
>
> Cheers
> Philippe
>
> > Ron
> >
> > > From: Philippe Marschall
> > > Sent: Sunday, February 11, 2007 12:01 PM
> >
> > >
> > > 2007/2/11, Ron Teitelbaum <[hidden email]>:
> > > > Hi all,
> > > > There are two version of Seaside2.7a1-nnn.169
> > > >
> > > > The pmm and mb.
> > > > Could we reconcile and merge the two versions?  Having two versions
> with
> > > the
> > > > same version number wreaks havoc with Monticello Configurations.
> > >
> > > Not to my experience since MCC takes the author initials into account.
> > > Later versions even use the UUID so even having two different versions
> > > with exactly the same filename works fine.
> > >
> >
> >
> >
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> From: Michael Roberts
> Sent: Monday, February 12, 2007 3:47 PM
>
> I agree with the general sentiments on both sides of the thread, but
> I am not sure I find this correct:
>
> > I only suggest that since
> > posting to the main path is intentional it should be respected and
> > that not
> > bothering to include someone else's changes is bad form.
>
> My understanding from talking to Lukas and Philippe is that anyone
> can post to SqueakSource/Seaside if that is what you mean by the main
> path.  This is to make it easy for the maintainers (anyone who merges
> regularly in the repository) to consider code.  I am free to post
> something bogus to the repository and for it to ultimately cause a
> discussion but no merge.  So I would agree with Philippe that the top
> number has no semantics.  You might have been very fortunate in the
> past the the 'head' revision has always been merged by lukas/philippe/
> michel/avi/whoever and therefore you can trust it because you trust
> these people.  I have had a head revision in the past but I wouldn't
> trust it; it's just a side effect of the upload before a maintainer
> merges it.  Lukas/Philippe do you see it this way?
>
> What I assume Philippe is saying is that we need some meta
> information in monticello to say 'this' version is the official one.
> I don't know if MCC does this or not.  In the past this has been done
> either via SM releases or more currently via Lukas' installer.  I am
> not sure there is any point to marking individual versions of
> monticello projects official or not.  Increasingly, projects are
> dependent on other projects and therefore they need to be grouped to
> have useful meaning. Is that MCC or does MCC do something else, or a
> subset?
>
> Cheers,
> Mike

> I agree with the general sentiments on both sides of the thread, but
> I am not sure I find this correct:
>
> > I only suggest that since
> > posting to the main path is intentional it should be respected and
> > that not
> > bothering to include someone else's changes is bad form.
>
> My understanding from talking to Lukas and Philippe is that anyone
> can post to SqueakSource/Seaside if that is what you mean by the main
> path.  This is to make it easy for the maintainers (anyone who merges
> regularly in the repository) to consider code.  I am free to post
> something bogus to the repository and for it to ultimately cause a
> discussion but no merge.

> So I would agree with Philippe that the top
> number has no semantics.  You might have been very fortunate in the
> past the the 'head' revision has always been merged by lukas/philippe/
> michel/avi/whoever and therefore you can trust it because you trust
> these people.  I have had a head revision in the past but I wouldn't
> trust it; it's just a side effect of the upload before a maintainer
> merges it.  Lukas/Philippe do you see it this way?
>
> What I assume Philippe is saying is that we need some meta
> information in monticello to say 'this' version is the official one.
> I don't know if MCC does this or not.  In the past this has been done
> either via SM releases or more currently via Lukas' installer.  I am
> not sure there is any point to marking individual versions of
> monticello projects official or not.  Increasingly, projects are
> dependent on other projects and therefore they need to be grouped to
> have useful meaning. Is that MCC or does MCC do something else, or a
> subset?

> path.  This is to make it easy for the maintainers (anyone who merges
> regularly in the repository) to consider code.  I am free to post
> something bogus to the repository and for it to ultimately cause a
> discussion but no merge.  So I would agree with Philippe that the top
> number has no semantics.  You might have been very fortunate in the
> past the the 'head' revision has always been merged by lukas/philippe/
> michel/avi/whoever and therefore you can trust it because you trust
> these people.  I have had a head revision in the past but I wouldn't
> trust it; it's just a side effect of the upload before a maintainer
> merges it.  Lukas/Philippe do you see it this way?

>> path.  This is to make it easy for the maintainers (anyone who merges
>> regularly in the repository) to consider code.  I am free to post
>> something bogus to the repository and for it to ultimately cause a
>> discussion but no merge.  So I would agree with Philippe that the top
>> number has no semantics.  You might have been very fortunate in the
>> past the the 'head' revision has always been merged by lukas/philippe/
>> michel/avi/whoever and therefore you can trust it because you trust
>> these people.  I have had a head revision in the past but I wouldn't
>> trust it; it's just a side effect of the upload before a maintainer
>> merges it.  Lukas/Philippe do you see it this way?
>
> Yep, exactly. Nice write-up.
>
> And in case of doubts or problems there is always the mailing-list
> where we can discuss about the changes.
>
> Cheers,
> Lukas
>