Does Pharo stores original author of methods?
Locked
Does Pharo stores original author of methods?
 
|
Hi.
Is information about original authors of methods exists in sources of image? I found only authors of last methods modification. Nautilus combobox source/timestamp. It will be useful to know who introduce some particular method to ask him questions directly. Now when we doing refactoring many methods become touched and this information become lost (searching repositories is not very easy now). |
Re: Does Pharo stores original author of methods?
|
|
> On 20 Nov 2015, at 09:46, Denis Kudriashov <[hidden email]> wrote: > > Hi. > > Is information about original authors of methods exists in sources of image? No. > I found only authors of last methods modification. Nautilus combobox source/timestamp. > > It will be useful to know who introduce some particular method to ask him questions directly. Now when we doing refactoring many methods become touched and this information become lost (searching repositories is not very easy now). Yes, repository search needs to be better. But we know that since 10 years. Marcus |
Re: Does Pharo stores original author of methods?
|
|
Maybe we should include this information in new changes system (Epicea?) 2015-11-20 13:50 GMT+01:00 Marcus Denker <[hidden email]>:
|
Re: Does Pharo stores original author of methods?
|
or just use git *run and hides* On Fri, Nov 20, 2015 at 3:04 PM Denis Kudriashov <[hidden email]> wrote:
|
Re: Does Pharo stores original author of methods?
|
|
In reply to this post by Denis Kudriashov
epicea data is not stored forever. It is seasion based and the shipped image is clean. This information needs to be in the repository. That is why one has a repository of code.
|
Re: Does Pharo stores original author of methods?
|
|
2015-11-20 14:21 GMT+01:00 Marcus Denker <[hidden email]>:
But current source of this info is changes file (maybe sources). And I remember you planned to store current sources in image. And such information can be there too. Maybe I miss something? |
Re: Does Pharo stores original author of methods?
|
|
The original author is not really that much of information. And storing it for every method in the image would take space. As I said: the whole idea of using a source revision control system is that you have the *complete* history available, but not wasting RAM. Marcus
|
|
Is there any reason against amending Monticello to store and save all
author's names? Presumably, we'd also want a tool that could extract amnders' names all the way back to the first commit of a package? How many on-line Monticello repositories are in common use? (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) Are there active administrators for each of those repositories that would allow us to update the repositories to use the updated Monticello? On 22 November 2015 at 15:42, Marcus Denker <[hidden email]> wrote: > > On 20 Nov 2015, at 14:35, Denis Kudriashov <[hidden email]> wrote: > > > 2015-11-20 14:21 GMT+01:00 Marcus Denker <[hidden email]>: >> >> epicea data is not stored forever. It is seasion based and the shipped >> image is >> clean. > > > But current source of this info is changes file (maybe sources). And I > remember you planned to store current sources in image. And such information > can be there too. > Maybe I miss something? > > > The original author is not really that much of information. And storing it > for every method in the image would take space. > > As I said: the whole idea of using a source revision control system is that > you have the *complete* history available, but > not wasting RAM. > > Marcus |
Re: Does Pharo stores original author of methods?
|
|
> On 22 Nov 2015, at 20:12, EuanM <[hidden email]> wrote: > > Is there any reason against amending Monticello to store and save all > author's names? It does. *If* you have all the versions… but doing anything with “all the versions” is so slow (you need to download them, unpack them…) that we do not even have a tool to show the history of a method. (getting the oldest should be simpler, if you have complete history+this .mcz is there). Monticello is meant to be a system to save the complete history of a project (if you keep all the MCZ available), but the idea to save every tiny revision as a complete snapshot, zip compresses, makes it near impossible to do anything with the history in practice. With today disks, a practical SCM would allow anyone to have the *complete* history on the local disk. Monticello does now allow that in any practical way. > > Presumably, we'd also want a tool that could extract amnders' names > all the way back to the first commit of a package? > > How many on-line Monticello repositories are in common use? > > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) > > Are there active administrators for each of those repositories that > would allow us to update the repositories to use the updated > Monticello? > > On 22 November 2015 at 15:42, Marcus Denker <[hidden email]> wrote: >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <[hidden email]> wrote: >> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <[hidden email]>: >>> >>> epicea data is not stored forever. It is seasion based and the shipped >>> image is >>> clean. >> >> >> But current source of this info is changes file (maybe sources). And I >> remember you planned to store current sources in image. And such information >> can be there too. >> Maybe I miss something? >> >> >> The original author is not really that much of information. And storing it >> for every method in the image would take space. >> >> As I said: the whole idea of using a source revision control system is that >> you have the *complete* history available, but >> not wasting RAM. >> >> Marcus > |
Re: Does Pharo stores original author of methods?
|
|
It's not Monticello per se. It's the backend (the server) which is too naive. The .mcz must be considered as a unit of exchange between the server (the repository) and the client (the working copy). And please note that in Monticello, it's not the only way to exchange data, it can also be a .mcd (a diff). Nothing forces the server to store the .mcz as is. That's just a naive implementation. Chris Muller demonstrated how to use a database (magma) as backend... 2015-11-23 12:12 GMT+01:00 Marcus Denker <[hidden email]>:
|
|
|
In reply to this post by Marcus Denker-4
I did not mean storing all versions. I mean storing all authors of previous veesions. On 23 Nov 2015 11:13, "Marcus Denker" <[hidden email]> wrote:
|
|
|
In reply to this post by Nicolas Cellier
+1
And so far Monticello is much better that having delta because you can still get a complete project without having to reconstruct the complete snapshot from deltas. I could not imagine the amount of code we would have lost else. Veronica in her PhD built a crawler that reconstructs all the deltas based on MC files. Now this is work. Stef Le 23/11/15 17:02, Nicolas Cellier a
écrit :
|
|
|
Is there anything stopping us adding one more dictionary to each
Monticello commit? A key of commit ids and values of author name? On 24 November 2015 at 06:55, stepharo <[hidden email]> wrote: > +1 > > And so far Monticello is much better that having delta because you can still > get a complete project without having to reconstruct the complete > snapshot from deltas. I could not imagine the amount of code we would have > lost else. > Veronica in her PhD built a crawler that reconstructs all the deltas based > on MC files. Now this is work. > Stef > > Le 23/11/15 17:02, Nicolas Cellier a écrit : > > It's not Monticello per se. It's the backend (the server) which is too > naive. > The .mcz must be considered as a unit of exchange between the server (the > repository) and the client (the working copy). And please note that in > Monticello, it's not the only way to exchange data, it can also be a .mcd (a > diff). > > Nothing forces the server to store the .mcz as is. That's just a naive > implementation. Chris Muller demonstrated how to use a database (magma) as > backend... > > 2015-11-23 12:12 GMT+01:00 Marcus Denker <[hidden email]>: >> >> >> > On 22 Nov 2015, at 20:12, EuanM <[hidden email]> wrote: >> > >> > Is there any reason against amending Monticello to store and save all >> > author's names? >> >> It does. *If* you have all the versions… but doing anything with “all the >> versions” >> is so slow (you need to download them, unpack them…) that we do not even >> have >> a tool to show the history of a method. >> (getting the oldest should be simpler, if you have complete history+this >> .mcz is >> there). >> >> Monticello is meant to be a system to save the complete history of a >> project >> (if you keep all the MCZ available), but the idea to save every tiny >> revision as >> a complete snapshot, zip compresses, makes it near impossible to do >> anything >> with the history in practice. >> >> With today disks, a practical SCM would allow anyone to have the >> *complete* >> history on the local disk. Monticello does now allow that in any practical >> way. >> >> > >> > Presumably, we'd also want a tool that could extract amnders' names >> > all the way back to the first commit of a package? >> > >> > How many on-line Monticello repositories are in common use? >> > >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) >> > >> > Are there active administrators for each of those repositories that >> > would allow us to update the repositories to use the updated >> > Monticello? >> > >> > On 22 November 2015 at 15:42, Marcus Denker <[hidden email]> >> > wrote: >> >> >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <[hidden email]> >> >> wrote: >> >> >> >> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <[hidden email]>: >> >>> >> >>> epicea data is not stored forever. It is seasion based and the shipped >> >>> image is >> >>> clean. >> >> >> >> >> >> But current source of this info is changes file (maybe sources). And I >> >> remember you planned to store current sources in image. And such >> >> information >> >> can be there too. >> >> Maybe I miss something? >> >> >> >> >> >> The original author is not really that much of information. And storing >> >> it >> >> for every method in the image would take space. >> >> >> >> As I said: the whole idea of using a source revision control system is >> >> that >> >> you have the *complete* history available, but >> >> not wasting RAM. >> >> >> >> Marcus >> > >> >> > > |
Re: Does Pharo stores original author of methods?
|
|
This dictionary is already there in the version metadata... The file that generates conflicts in git. Thierry > On 24 November 2015 at 06:55, stepharo <[hidden email]> wrote: |
|
|
Does git not allow additional attribute objects that it benignly
stores and ignores? (I suspect I can guess the answer, but...) On 30 November 2015 at 05:55, Thierry Goubier <[hidden email]> wrote: > > Le 30 nov. 2015 5:24 AM, "EuanM" <[hidden email]> a écrit : >> >> Is there anything stopping us adding one more dictionary to each >> Monticello commit? >> >> A key of commit ids and values of author name? > > This dictionary is already there in the version metadata... The file that > generates conflicts in git. > > Thierry > >> On 24 November 2015 at 06:55, stepharo <[hidden email]> wrote: >> > +1 >> > >> > And so far Monticello is much better that having delta because you can >> > still >> > get a complete project without having to reconstruct the complete >> > snapshot from deltas. I could not imagine the amount of code we would >> > have >> > lost else. >> > Veronica in her PhD built a crawler that reconstructs all the deltas >> > based >> > on MC files. Now this is work. >> > Stef >> > >> > Le 23/11/15 17:02, Nicolas Cellier a écrit : >> > >> > It's not Monticello per se. It's the backend (the server) which is too >> > naive. >> > The .mcz must be considered as a unit of exchange between the server >> > (the >> > repository) and the client (the working copy). And please note that in >> > Monticello, it's not the only way to exchange data, it can also be a >> > .mcd (a >> > diff). >> > >> > Nothing forces the server to store the .mcz as is. That's just a naive >> > implementation. Chris Muller demonstrated how to use a database (magma) >> > as >> > backend... >> > >> > 2015-11-23 12:12 GMT+01:00 Marcus Denker <[hidden email]>: >> >> >> >> >> >> > On 22 Nov 2015, at 20:12, EuanM <[hidden email]> wrote: >> >> > >> >> > Is there any reason against amending Monticello to store and save all >> >> > author's names? >> >> >> >> It does. *If* you have all the versions… but doing anything with “all >> >> the >> >> versions” >> >> is so slow (you need to download them, unpack them…) that we do not >> >> even >> >> have >> >> a tool to show the history of a method. >> >> (getting the oldest should be simpler, if you have complete >> >> history+this >> >> .mcz is >> >> there). >> >> >> >> Monticello is meant to be a system to save the complete history of a >> >> project >> >> (if you keep all the MCZ available), but the idea to save every tiny >> >> revision as >> >> a complete snapshot, zip compresses, makes it near impossible to do >> >> anything >> >> with the history in practice. >> >> >> >> With today disks, a practical SCM would allow anyone to have the >> >> *complete* >> >> history on the local disk. Monticello does now allow that in any >> >> practical >> >> way. >> >> >> >> > >> >> > Presumably, we'd also want a tool that could extract amnders' names >> >> > all the way back to the first commit of a package? >> >> > >> >> > How many on-line Monticello repositories are in common use? >> >> > >> >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) >> >> > >> >> > Are there active administrators for each of those repositories that >> >> > would allow us to update the repositories to use the updated >> >> > Monticello? >> >> > >> >> > On 22 November 2015 at 15:42, Marcus Denker <[hidden email]> >> >> > wrote: >> >> >> >> >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <[hidden email]> >> >> >> wrote: >> >> >> >> >> >> >> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <[hidden email]>: >> >> >>> >> >> >>> epicea data is not stored forever. It is seasion based and the >> >> >>> shipped >> >> >>> image is >> >> >>> clean. >> >> >> >> >> >> >> >> >> But current source of this info is changes file (maybe sources). And >> >> >> I >> >> >> remember you planned to store current sources in image. And such >> >> >> information >> >> >> can be there too. >> >> >> Maybe I miss something? >> >> >> >> >> >> >> >> >> The original author is not really that much of information. And >> >> >> storing >> >> >> it >> >> >> for every method in the image would take space. >> >> >> >> >> >> As I said: the whole idea of using a source revision control system >> >> >> is >> >> >> that >> >> >> you have the *complete* history available, but >> >> >> not wasting RAM. >> >> >> >> >> >> Marcus >> >> > >> >> >> >> >> > >> > >> |
|
|
There is git-notes...
http://git-scm.com/docs/git-notes but it seems a little complicated to manage... "Git notes are annotations for existing commits. They don’t change the history, so you are free to add notes to any existing commits. Your notes are stored only in your repo, but it’s possible to share notes. " http://mislav.net/2010/07/git-tips/ http://lists-archives.com/git/714256-git-notes-usage.html cheers -ben On Mon, Nov 30, 2015 at 2:41 PM, EuanM <[hidden email]> wrote: > Does git not allow additional attribute objects that it benignly > stores and ignores? (I suspect I can guess the answer, but...) > > On 30 November 2015 at 05:55, Thierry Goubier <[hidden email]> wrote: >> >> Le 30 nov. 2015 5:24 AM, "EuanM" <[hidden email]> a écrit : >>> >>> Is there anything stopping us adding one more dictionary to each >>> Monticello commit? >>> >>> A key of commit ids and values of author name? >> >> This dictionary is already there in the version metadata... The file that >> generates conflicts in git. >> >> Thierry >> >>> On 24 November 2015 at 06:55, stepharo <[hidden email]> wrote: >>> > +1 >>> > >>> > And so far Monticello is much better that having delta because you can >>> > still >>> > get a complete project without having to reconstruct the complete >>> > snapshot from deltas. I could not imagine the amount of code we would >>> > have >>> > lost else. >>> > Veronica in her PhD built a crawler that reconstructs all the deltas >>> > based >>> > on MC files. Now this is work. >>> > Stef >>> > >>> > Le 23/11/15 17:02, Nicolas Cellier a écrit : >>> > >>> > It's not Monticello per se. It's the backend (the server) which is too >>> > naive. >>> > The .mcz must be considered as a unit of exchange between the server >>> > (the >>> > repository) and the client (the working copy). And please note that in >>> > Monticello, it's not the only way to exchange data, it can also be a >>> > .mcd (a >>> > diff). >>> > >>> > Nothing forces the server to store the .mcz as is. That's just a naive >>> > implementation. Chris Muller demonstrated how to use a database (magma) >>> > as >>> > backend... >>> > >>> > 2015-11-23 12:12 GMT+01:00 Marcus Denker <[hidden email]>: >>> >> >>> >> >>> >> > On 22 Nov 2015, at 20:12, EuanM <[hidden email]> wrote: >>> >> > >>> >> > Is there any reason against amending Monticello to store and save all >>> >> > author's names? >>> >> >>> >> It does. *If* you have all the versions… but doing anything with “all >>> >> the >>> >> versions” >>> >> is so slow (you need to download them, unpack them…) that we do not >>> >> even >>> >> have >>> >> a tool to show the history of a method. >>> >> (getting the oldest should be simpler, if you have complete >>> >> history+this >>> >> .mcz is >>> >> there). >>> >> >>> >> Monticello is meant to be a system to save the complete history of a >>> >> project >>> >> (if you keep all the MCZ available), but the idea to save every tiny >>> >> revision as >>> >> a complete snapshot, zip compresses, makes it near impossible to do >>> >> anything >>> >> with the history in practice. >>> >> >>> >> With today disks, a practical SCM would allow anyone to have the >>> >> *complete* >>> >> history on the local disk. Monticello does now allow that in any >>> >> practical >>> >> way. >>> >> >>> >> > >>> >> > Presumably, we'd also want a tool that could extract amnders' names >>> >> > all the way back to the first commit of a package? >>> >> > >>> >> > How many on-line Monticello repositories are in common use? >>> >> > >>> >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) >>> >> > >>> >> > Are there active administrators for each of those repositories that >>> >> > would allow us to update the repositories to use the updated >>> >> > Monticello? >>> >> > >>> >> > On 22 November 2015 at 15:42, Marcus Denker <[hidden email]> >>> >> > wrote: >>> >> >> >>> >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <[hidden email]> >>> >> >> wrote: >>> >> >> >>> >> >> >>> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <[hidden email]>: >>> >> >>> >>> >> >>> epicea data is not stored forever. It is seasion based and the >>> >> >>> shipped >>> >> >>> image is >>> >> >>> clean. >>> >> >> >>> >> >> >>> >> >> But current source of this info is changes file (maybe sources). And >>> >> >> I >>> >> >> remember you planned to store current sources in image. And such >>> >> >> information >>> >> >> can be there too. >>> >> >> Maybe I miss something? >>> >> >> >>> >> >> >>> >> >> The original author is not really that much of information. And >>> >> >> storing >>> >> >> it >>> >> >> for every method in the image would take space. >>> >> >> >>> >> >> As I said: the whole idea of using a source revision control system >>> >> >> is >>> >> >> that >>> >> >> you have the *complete* history available, but >>> >> >> not wasting RAM. >>> >> >> >>> >> >> Marcus >>> >> > >>> >> >>> >> >>> > >>> > >>> > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |