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 > > Method history is so much more useful than 20 extra MB's on my HD :S Cheers, Henry |
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 |
+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 > > |
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 > 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 |
> 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 |
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 |
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 |
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 |
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 > |
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 > 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 |
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 > |
In reply to this post by Henrik Sperre Johansen
On Tue, Sep 20, 2011 at 5:53 AM, Henrik Sperre Johansen <[hidden email]> 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.
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 <[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 > |
In reply to this post by Eliot Miranda-2
On 20.09.2011 21:32, Eliot Miranda wrote:
Can't speak for the others, but I would _very_ much appreciate that being the default. Cheers, Henry |
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 |
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. 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 best, Eliot condenseChanges.st (12K) Download Attachment |
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. |
In reply to this post by Eliot Miranda-2
Eliot Miranda wrote:
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. |
>>
>> 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 |
Free forum by Nabble | Edit this page |