[1.4] Doing a #condenseChanges in #14158

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[1.4] Doing a #condenseChanges in #14158

Marcus Denker-4
Hi,

The .changes have gotten really large... (32MB...)

So I will do a condense in the next update.

NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...

        Marcus


--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Henrik Sperre Johansen
On 20.09.2011 14:49, Marcus Denker wrote:

> Hi,
>
> The .changes have gotten really large... (32MB...)
>
> So I will do a condense in the next update.
>
> NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...
>
> Marcus
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>
Noooooooooo, please please don't...
Method history is so much more useful than 20 extra MB's on my HD :S

Cheers,
Henry

Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Marcus Denker-4
In reply to this post by Marcus Denker-4

On Sep 20, 2011, at 2:54 PM, Henrik Sperre Johansen wrote:

> On 20.09.2011 14:49, Marcus Denker wrote:
>> Hi,
>>
>> The .changes have gotten really large... (32MB...)
>>
>> So I will do a condense in the next update.
>>
>> NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...
>>
>> Marcus
>>
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>
> Noooooooooo, please please don't...
> Method history is so much more useful than 20 extra MB's on my HD :S


Ok, so lets postpone... but we really need to think hard how this is sustainable.

I have the impression that the current source management system needs some
real improvement soon.

        Marcus


--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Benjamin Van Ryseghem (Pharo)
+1


Ben

On Sep 20, 2011, at 3:05 PM, Marcus Denker wrote:

>
> On Sep 20, 2011, at 2:54 PM, Henrik Sperre Johansen wrote:
>
>> On 20.09.2011 14:49, Marcus Denker wrote:
>>> Hi,
>>>
>>> The .changes have gotten really large... (32MB...)
>>>
>>> So I will do a condense in the next update.
>>>
>>> NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...
>>>
>>> Marcus
>>>
>>>
>>> --
>>> Marcus Denker -- http://marcusdenker.de
>>>
>>>
>> Noooooooooo, please please don't...
>> Method history is so much more useful than 20 extra MB's on my HD :S
>
>
> Ok, so lets postpone... but we really need to think hard how this is sustainable.
>
> I have the impression that the current source management system needs some
> real improvement soon.
>
> Marcus
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Henrik Sperre Johansen
In reply to this post by Marcus Denker-4
On 20.09.2011 15:05, Marcus Denker wrote:

> On Sep 20, 2011, at 2:54 PM, Henrik Sperre Johansen wrote:
>
>> On 20.09.2011 14:49, Marcus Denker wrote:
>>> Hi,
>>>
>>> The .changes have gotten really large... (32MB...)
>>>
>>> So I will do a condense in the next update.
>>>
>>> NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...
>>>
>>> Marcus
>>>
>>>
>>> --
>>> Marcus Denker -- http://marcusdenker.de
>>>
>>>
>> Noooooooooo, please please don't...
>> Method history is so much more useful than 20 extra MB's on my HD :S
>
> Ok, so lets postpone... but we really need to think hard how this is sustainable.
>
> I have the impression that the current source management system needs some
> real improvement soon.
>
> Marcus
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
Can only speak from personal experience...
When encountering a bug in some recently changed method, your only
chance is manually diff each package from around the changeset
timestamp, and you'll hopefully be able to link it to the issue that
prompted the change...

Now imagine this when there are nothing but most recent versions in the
.cs, and some syntactic changes were made after that which actually
introduced the bug?
Yup, (imho) condensing changes make linking method changes back to the
issues which prompted them practically impossible. (and before that,
it's still a PITA)

Performant method history browsing from Monticello repositories is never
going to be a reality.
I'd gladly give 100 € (or a beer, whichever is preferred) to someone who
can prove me wrong :)

Cheers,
Henry

Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Lukas Renggli
> Performant method history browsing from Monticello repositories is never
> going to be a reality.
> I'd gladly give 100 € (or a beer, whichever is preferred) to someone who can
> prove me wrong :)

It is reality since 3+ years in Monticello 2.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Sven Van Caekenberghe
In reply to this post by Henrik Sperre Johansen

On 20 Sep 2011, at 15:20, Henrik Sperre Johansen wrote:

> Performant method history browsing from Monticello repositories is never going to be a reality.
> I'd gladly give 100 € (or a beer, whichever is preferred) to someone who can prove me wrong :)

Where you live beers are quite expensive ;-) !

Both points are valid: .changes files that are too big are not very good, having method history of methods is important.

Maybe someone should try to find out how many identical entries there are in the current ? It could well be that there are a lot of those due to the way integrations are done ?

Sven


Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Henrik Sperre Johansen
In reply to this post by Lukas Renggli
On 20.09.2011 15:26, Lukas Renggli wrote:
>> Performant method history browsing from Monticello repositories is never
>> going to be a reality.
>> I'd gladly give 100 € (or a beer, whichever is preferred) to someone who can
>> prove me wrong :)
> It is reality since 3+ years in Monticello 2.
>
> Lukas
>
Monticello 2 != Monticello, sadly

Cheers,
Henry

Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Marcus Denker-4
In reply to this post by Lukas Renggli

On Sep 20, 2011, at 3:29 PM, Henrik Sperre Johansen wrote:

> On 20.09.2011 15:26, Lukas Renggli wrote:
>>> Performant method history browsing from Monticello repositories is never
>>> going to be a reality.
>>> I'd gladly give 100 € (or a beer, whichever is preferred) to someone who can
>>> prove me wrong :)
>> It is reality since 3+ years in Monticello 2.
>>
>> Lukas
>>
> Monticello 2 != Monticello, sadly


But if it works since 3 years, why don't we use it and retire Monticello 1?

        Marcus


--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Gary Chambers-4
In reply to this post by Henrik Sperre Johansen
Perhaps a semi-condense that keeps the last two or three?

Regards, Gary

----- Original Message -----
From: "Henrik Sperre Johansen" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, September 20, 2011 1:53 PM
Subject: Re: [Pharo-project] [1.4] Doing a #condenseChanges in #14158


> On 20.09.2011 14:49, Marcus Denker wrote:
>> Hi,
>>
>> The .changes have gotten really large... (32MB...)
>>
>> So I will do a condense in the next update.
>>
>> NOTE: this will take quite some time to finish, so maybe wait for a
>> pre-built image or Jenkins...
>>
>> Marcus
>>
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>
> Noooooooooo, please please don't...
> Method history is so much more useful than 20 extra MB's on my HD :S
>
> Cheers,
> Henry
>


Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Henrik Sperre Johansen
In reply to this post by Marcus Denker-4
On 20.09.2011 15:39, Marcus Denker wrote:

> On Sep 20, 2011, at 3:29 PM, Henrik Sperre Johansen wrote:
>
>> On 20.09.2011 15:26, Lukas Renggli wrote:
>>>> Performant method history browsing from Monticello repositories is never
>>>> going to be a reality.
>>>> I'd gladly give 100 € (or a beer, whichever is preferred) to someone who can
>>>> prove me wrong :)
>>> It is reality since 3+ years in Monticello 2.
>>>
>>> Lukas
>>>
>> Monticello 2 != Monticello, sadly
>
> But if it works since 3 years, why don't we use it and retire Monticello 1?
>
> Marcus
>
Effort?
I wouldn't mind switching as soon as someone:
- Rewrites the update process
- Writes a translator for MC1 -> MC2 repositories
- Figures out how/if we support loading code from/to MC1/MC2 without
users getting confused
- Makes sure the tools are at least as good, and don't rely on
frameworks not in Core

There's sure to be more things which needs doing, some of the ones
listed above may already have been done?
I know next to nothing about MC2 other than it being a complete rewrite
with incompatible format and better granularity...

Cheers,
Henry

Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Stéphane Ducasse
In reply to this post by Henrik Sperre Johansen
Henrik

veronica and andy are working on ring for that providing an infrasturcture to support history browsing:)
Now Veronica could need some inputs:

        - could you write some typical scenario you would like to get solved?
                I personally want to see the senders in the past and compare then with the current version :)

        - Veronica could need some help to write more tests and build a nice infrastructure
        so if some smart people would like to help I'm sure we could do something quite nice.

Stef



>> The .changes have gotten really large... (32MB...)
>>
>> So I will do a condense in the next update.
>>
>> NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...
>>
>> Marcus
>>
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>
> Noooooooooo, please please don't...
> Method history is so much more useful than 20 extra MB's on my HD :S
>
> Cheers,
> Henry
>


Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Eliot Miranda-2
In reply to this post by Henrik Sperre Johansen


On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen <[hidden email]> wrote:
On 20.09.2011 14:49, Marcus Denker wrote:
Hi,

The .changes have gotten really large... (32MB...)

So I will do a condense in the next update.

NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...

       Marcus


--
Marcus Denker -- http://marcusdenker.de


Noooooooooo, please please don't...
Method history is so much more useful than 20 extra MB's on my HD :S

This is /not/ a dichotomy.  For my image I wrote a condenseSources that preserves history.  It edits out duplicates, and cuts off branches in the history that lead nowhere.  So at the end you get all the versions of each method that are ancestors of the current version.  I can email you the code and you could consider making it the default.  Let me know.
 

Cheers,
Henry




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Stéphane Ducasse
yes please send it.
How do you determine ancestry?
Stef

On Sep 20, 2011, at 9:32 PM, Eliot Miranda wrote:

>
>
> On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen <[hidden email]> wrote:
> On 20.09.2011 14:49, Marcus Denker wrote:
> Hi,
>
> The .changes have gotten really large... (32MB...)
>
> So I will do a condense in the next update.
>
> NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...
>
>        Marcus
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>
> Noooooooooo, please please don't...
> Method history is so much more useful than 20 extra MB's on my HD :S
>
> This is /not/ a dichotomy.  For my image I wrote a condenseSources that preserves history.  It edits out duplicates, and cuts off branches in the history that lead nowhere.  So at the end you get all the versions of each method that are ancestors of the current version.  I can email you the code and you could consider making it the default.  Let me know.
>  
>
> Cheers,
> Henry
>
>
>
>
> --
> best,
> Eliot
>


Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Henrik Sperre Johansen
In reply to this post by Eliot Miranda-2
On 20.09.2011 21:32, Eliot Miranda wrote:


On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen <[hidden email]> wrote:
On 20.09.2011 14:49, Marcus Denker wrote:
Hi,

The .changes have gotten really large... (32MB...)

So I will do a condense in the next update.

NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...

       Marcus


--
Marcus Denker -- http://marcusdenker.de


Noooooooooo, please please don't...
Method history is so much more useful than 20 extra MB's on my HD :S

This is /not/ a dichotomy.  For my image I wrote a condenseSources that preserves history.  It edits out duplicates, and cuts off branches in the history that lead nowhere.  So at the end you get all the versions of each method that are ancestors of the current version.  I can email you the code and you could consider making it the default.  Let me know.

Can't speak for the others, but I would _very_ much appreciate that being the default.

Cheers,
Henry
Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Marcus Denker-4
In reply to this post by Eliot Miranda-2

On Sep 20, 2011, at 9:55 PM, Henrik Sperre Johansen wrote:

>>
>> This is /not/ a dichotomy.  For my image I wrote a condenseSources that preserves history.  It edits out duplicates, and cuts off branches in the history that lead nowhere.  So at the end you get all the versions of each method that are ancestors of the current version.  I can email you the code and you could consider making it the default.  Let me know.
>
> Can't speak for the others, but I would _very_ much appreciate that being the default.

Yes, and run regularly...

        Marcus


--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Eliot Miranda-2
In reply to this post by Stéphane Ducasse


On Tue, Sep 20, 2011 at 12:50 PM, Stéphane Ducasse <[hidden email]> wrote:
yes please send it.
How do you determine ancestry?

Here's the phrase:

ChangeSet directAncestryOfVersions: (ChangeSet
scanVersionsOf: method 
class: self 
meta: self isMeta
category: category 
selector: selector)

the scanVersionsOf: is standard, and then I added directAncestryOfVersions: to filter appropriately.


Find attached.  You'll need to understand it, test it and integrate it, but it worked fine for me.  I haven't had time or occasion to push it to Squeak trunk.  But if people like it I'll think about doing so.  I agree with Henrik that this is a useful default.  I love method versions, and noise is noise, so this is having one's cake and eating it too :)

Enjoy!

Stef

On Sep 20, 2011, at 9:32 PM, Eliot Miranda wrote:

>
>
> On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen <[hidden email]> wrote:
> On 20.09.2011 14:49, Marcus Denker wrote:
> Hi,
>
> The .changes have gotten really large... (32MB...)
>
> So I will do a condense in the next update.
>
> NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...
>
>        Marcus
>
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>
> Noooooooooo, please please don't...
> Method history is so much more useful than 20 extra MB's on my HD :S
>
> This is /not/ a dichotomy.  For my image I wrote a condenseSources that preserves history.  It edits out duplicates, and cuts off branches in the history that lead nowhere.  So at the end you get all the versions of each method that are ancestors of the current version.  I can email you the code and you could consider making it the default.  Let me know.
>
>
> Cheers,
> Henry
>
>
>
>
> --
> best,
> Eliot
>





--
best,
Eliot


condenseChanges.st (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Igor Stasenko
On 20 September 2011 22:02, Eliot Miranda <[hidden email]> wrote:

>
>
> On Tue, Sep 20, 2011 at 12:50 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>>
>> yes please send it.
>> How do you determine ancestry?
>
> Here's the phrase:
> ChangeSet directAncestryOfVersions: (ChangeSet
> scanVersionsOf: method
> class: self
> meta: self isMeta
> category: category
> selector: selector)
> the scanVersionsOf: is standard, and then I added directAncestryOfVersions:
> to filter appropriately.
>
> Find attached.  You'll need to understand it, test it and integrate it, but
> it worked fine for me.  I haven't had time or occasion to push it to Squeak
> trunk.  But if people like it I'll think about doing so.  I agree with
> Henrik that this is a useful default.  I love method versions, and noise is
> noise, so this is having one's cake and eating it too :)

+1

> Enjoy!
>>
>> Stef
>>
>> On Sep 20, 2011, at 9:32 PM, Eliot Miranda wrote:
>>
>> >
>> >
>> > On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen
>> > <[hidden email]> wrote:
>> > On 20.09.2011 14:49, Marcus Denker wrote:
>> > Hi,
>> >
>> > The .changes have gotten really large... (32MB...)
>> >
>> > So I will do a condense in the next update.
>> >
>> > NOTE: this will take quite some time to finish, so maybe wait for a
>> > pre-built image or Jenkins...
>> >
>> >        Marcus
>> >
>> >
>> > --
>> > Marcus Denker -- http://marcusdenker.de
>> >
>> >
>> > Noooooooooo, please please don't...
>> > Method history is so much more useful than 20 extra MB's on my HD :S
>> >
>> > This is /not/ a dichotomy.  For my image I wrote a condenseSources that
>> > preserves history.  It edits out duplicates, and cuts off branches in the
>> > history that lead nowhere.  So at the end you get all the versions of each
>> > method that are ancestors of the current version.  I can email you the code
>> > and you could consider making it the default.  Let me know.
>> >
>> >
>> > Cheers,
>> > Henry
>> >
>> >
>> >
>> >
>> > --
>> > best,
>> > Eliot
>> >
>>
>>
>
>
>
> --
> best,
> Eliot
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Ben Coman
In reply to this post by Eliot Miranda-2
Eliot Miranda wrote:


On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen <[hidden email]> wrote:
On 20.09.2011 14:49, Marcus Denker wrote:
Hi,

The .changes have gotten really large... (32MB...)

So I will do a condense in the next update.

NOTE: this will take quite some time to finish, so maybe wait for a pre-built image or Jenkins...

       Marcus


--
Marcus Denker -- http://marcusdenker.de


Noooooooooo, please please don't...
Method history is so much more useful than 20 extra MB's on my HD :S

This is /not/ a dichotomy.  For my image I wrote a condenseSources that preserves history.  It edits out duplicates, and cuts off branches in the history that lead nowhere.  So at the end you get all the versions of each method that are ancestors of the current version.  I can email you the code and you could consider making it the default.  Let me know.
 

Cheers,
Henry




--
best,
Eliot

What about having a changes file per release?  Each .changes file records its predecessor file - including md5checksum.  The search just parses multiple files.
.changes.1.0
.changes.1.1
.changes.1.2
.changes.current

In theory, anyone can decide on an individual basis how far back to keep history.  An image could be shrunk for a client deliverable but easily added back in to troubleshoot the client's live image.
Reply | Threaded
Open this post in threaded view
|

Re: [1.4] Doing a #condenseChanges in #14158

Stéphane Ducasse
>>
>> Noooooooooo, please please don't...
>> Method history is so much more useful than 20 extra MB's on my HD :S
>>
>> This is /not/ a dichotomy.  For my image I wrote a condenseSources that preserves history.  It edits out duplicates, and cuts off branches in the history that lead nowhere.  So at the end you get all the versions of each method that are ancestors of the current version.  I can email you the code and you could consider making it the default.  Let me know.
>>  
>>
>> Cheers,
>> Henry
>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
> What about having a changes file per release?  Each .changes file records its predecessor file - including md5checksum.  The search just parses multiple files.
> .changes.1.0
> .changes.1.1
> .changes.1.2
> .changes.current
>
> In theory, anyone can decide on an individual basis how far back to keep history.  An image could be shrunk for a client deliverable but easily added back in to troubleshoot the client's live image.

ideally we would love to have a little db can branch to existing one or distributed one and keep all the non redundant changes.
Now it requires a lot of work.

Stef