[Pharo-project] [1.4] Doing a #condenseChanges in #14158
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
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
Perhaps a semi-condense that keeps the last two or three? Regards, Gary ----- Original Message ----- From: "Henrik Sperre Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> 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
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
On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> 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
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 <henrik.s.johansen@veloxit.no> 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
On Tue, Sep 20, 2011 at 12:50 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> 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 <
henrik.s.johansen@veloxit.no> 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
On 20 September 2011 22:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Sep 20, 2011 at 12:50 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 <henrik.s.johansen@veloxit.no> 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.
On 20.09.2011 21:32, Eliot Miranda wrote:
On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> 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
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
participants (7)
-
btc＠openInWorld.com -
Eliot Miranda -
Gary Chambers -
Henrik Sperre Johansen -
Igor Stasenko -
Marcus Denker -
Stéphane Ducasse