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).
On 20 Nov 2015, at 09:46, Denis Kudriashov <dionisiydk@gmail.com> 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
Maybe we should include this information in new changes system (Epicea?) 2015-11-20 13:50 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 20 Nov 2015, at 09:46, Denis Kudriashov <dionisiydk@gmail.com> 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
or just use git *run and hides* On Fri, Nov 20, 2015 at 3:04 PM Denis Kudriashov <dionisiydk@gmail.com> wrote:
Maybe we should include this information in new changes system (Epicea?)
2015-11-20 13:50 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 20 Nov 2015, at 09:46, Denis Kudriashov <dionisiydk@gmail.com> 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
On 20 Nov 2015, at 10:03, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Maybe we should include this information in new changes system (Epicea?)
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.
2015-11-20 13:50 GMT+01:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>:
On 20 Nov 2015, at 09:46, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> 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
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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?
On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>: 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
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 <marcus.denker@inria.fr> wrote:
On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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
On 22 Nov 2015, at 20:12, EuanM <euanmee@gmail.com> 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 <marcus.denker@inria.fr> wrote:
On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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
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 <marcus.denker@inria.fr>:
On 22 Nov 2015, at 20:12, EuanM <euanmee@gmail.com> 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 <marcus.denker@inria.fr>
wrote:
On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com>
wrote:
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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
+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 <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>:
> On 22 Nov 2015, at 20:12, EuanM <euanmee@gmail.com <mailto:euanmee@gmail.com>> 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 <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>: >>> >>> 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 >
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 <stepharo@free.fr> 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 <marcus.denker@inria.fr>:
On 22 Nov 2015, at 20:12, EuanM <euanmee@gmail.com> 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 <marcus.denker@inria.fr> wrote:
On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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
Le 30 nov. 2015 5:24 AM, "EuanM" <euanmee@gmail.com> 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 <stepharo@free.fr> 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 <marcus.denker@inria.fr>:
On 22 Nov 2015, at 20:12, EuanM <euanmee@gmail.com> 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 <marcus.denker@inria.fr> wrote:
On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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
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 <thierry.goubier@gmail.com> wrote:
Le 30 nov. 2015 5:24 AM, "EuanM" <euanmee@gmail.com> 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 <stepharo@free.fr> 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 <marcus.denker@inria.fr>:
On 22 Nov 2015, at 20:12, EuanM <euanmee@gmail.com> 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 <marcus.denker@inria.fr> wrote:
On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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 <euanmee@gmail.com> 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 <thierry.goubier@gmail.com> wrote:
Le 30 nov. 2015 5:24 AM, "EuanM" <euanmee@gmail.com> 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 <stepharo@free.fr> 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 <marcus.denker@inria.fr>:
On 22 Nov 2015, at 20:12, EuanM <euanmee@gmail.com> 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 <marcus.denker@inria.fr> wrote:
On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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
I did not mean storing all versions. I mean storing all authors of previous veesions. On 23 Nov 2015 11:13, "Marcus Denker" <marcus.denker@inria.fr> wrote:
On 22 Nov 2015, at 20:12, EuanM <euanmee@gmail.com> 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 <marcus.denker@inria.fr>
wrote:
On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk@gmail.com>
wrote:
2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
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
participants (8)
-
Ben Coman -
Denis Kudriashov -
Dimitris Chloupis -
EuanM -
Marcus Denker -
Nicolas Cellier -
stepharo -
Thierry Goubier