Max wrote
In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.
Iâm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that leads to another set of problems. My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest? Stephan
On 06.03.2014, at 18:03, Stephan Eggermont <stephan@stack.nl> wrote:
Max wrote
In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.
Iâm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that leads to another set of problems.
I agree that we have to keep that in mind. And you are right that one file per method may be too granular. But at the moment (and I certainly have not done exhaustive work on this) I have no better solution. Since this is part of my Masterâs thesis, the scope of what I have time for is limited and I will be very glad if I manage to finish FileSystem-Git. Iâd rather not invent something, that then will turn out to be sub par and rather go with established protocols / methods, which may be inferior to a different solution, but of which I can at least estimate the possible drawbacks. This is not to say, that I donât want to achieve the best that is possible, Iâm just trying to avoid disappointment :)
My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest?
Well, of course that is not generally the case, but when working with pack files, it can be. Pack files do have indexes and fanout tables, so searching for an object is easy. But usually, contrary to loose objects, objects in packs will be deltified to a certain degree (more deltas the more objects there are) and deltification incurs the cost of putting the object back together (a delta chain can be of any length in theory), which means multpile offset calculations and searches on the stream. In average (and this is just an educated guess) the access time will thus be greater than for loose objects. Max
Stephan
Stephan, The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis. At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ... So you can use "blame" to view a line by line history of the method modifications ... If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ... Dale On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Max wrote
In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.
I'm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I don't want to suggest switching to a larger granularity, as that leads to another set of problems.
My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest?
Stephan
On 06.03.2014, at 21:18, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Stephan,
The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis.
At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ...
So you can use "blame" to view a line by line history of the method modifications ...
If one starts clumping methods into files, then you lose all method history when it moves from one clump to another â¦
Ah, I knew I had forgotten something :D Thanks Dale
Dale
On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan@stack.nl> wrote: Max wrote
In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.
Iâm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that leads to another set of problems.
My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest?
Stephan
On Thu, Mar 6, 2014 at 12:18 PM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Stephan,
The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis.
the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks. But why do you need command-line diff tools? If one spends most of one's time in Pharo why not have diff tools there-in and avoid all these contortions to appease a primitive VCS? You're already hitting thins like filename length limits in the mapping, and you're hitting performance problems. The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ...
So you can use "blame" to view a line by line history of the method modifications ...
If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ...
Dale
On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan@stack.nl>wrote:
Max wrote
In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.
I'm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I don't want to suggest switching to a larger granularity, as that leads to another set of problems.
My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest?
Stephan
-- best, Eliot
On 06.03.2014, at 22:14, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Thu, Mar 6, 2014 at 12:18 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote: Stephan,
The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis.
the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks.
But why do you need command-line diff tools?
We donât. Diffing has nothing to do with this (or only little). But if a method has its own file, then the hash of that method will be stable as long as it is unchanged, regardless of the number of commits it is referenced by. This makes it very easy to identify the changes that have been made to a particular method. How these changes are *visualized* is a different matter (and I would like to have a nice GUI for that too).
If one spends most of one's time in Pharo why not have diff tools there-in and avoid all these contortions to appease a primitive VCS? You're already hitting thins like filename length limits in the mapping, and you're hitting performance problems.
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ...
So you can use "blame" to view a line by line history of the method modifications ...
If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ...
Dale
On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan@stack.nl> wrote: Max wrote
In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.
Iâm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that leads to another set of problems.
My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest?
Stephan
-- best, Eliot
Le 06/03/2014 23:01, Max Leske a écrit :
On 06.03.2014, at 22:14, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks.
Can be done for git diffing and large files, so no need to push the blame on git. We just need someone to write the tools in Smalltalk.
But why do you need command-line diff tools?
We donât. Diffing has nothing to do with this (or only little). But if a method has its own file, then the hash of that method will be stable as long as it is unchanged, regardless of the number of commits it is referenced by. This makes it very easy to identify the changes that have been made to a particular method. How these changes are *visualized* is a different matter (and I would like to have a nice GUI for that too).
I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 07.03.2014, at 09:08, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 06/03/2014 23:01, Max Leske a écrit :
On 06.03.2014, at 22:14, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks.
Can be done for git diffing and large files, so no need to push the blame on git. We just need someone to write the tools in Smalltalk.
But why do you need command-line diff tools?
We donât. Diffing has nothing to do with this (or only little). But if a method has its own file, then the hash of that method will be stable as long as it is unchanged, regardless of the number of commits it is referenced by. This makes it very easy to identify the changes that have been made to a particular method. How these changes are *visualized* is a different matter (and I would like to have a nice GUI for that too).
I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe.
Is it on Smalltalkhub? Iâd like to take a look if you let me.
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 07/03/2014 09:25, Max Leske a écrit :
I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe.
Is it on Smalltalkhub? Iâd like to take a look if you let me.
It's on github :) https://github.com/ThierryGoubier/AltBrowser/tree/pharo3.0/Alt-Browser.packa... and the git interface lives inside gitfiletree, at: https://github.com/dalehenrich/filetree/blob/issue_124/repository/Monticello... Also available via ConfigurationOfGitFileTree. I'd be especially interested to know if, the way you're planning to do it, will allow to: - Better track methods among class renames, package renames, ownership in packages and so on: mine I think get the commits for all versions of a method right, but is limited in its ability to find them through renames (since each version path name may be different from the current one). - And be able to rebuild package version history via the VCS history, as I do now in gitfiletree. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 07.03.2014, at 09:37, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 07/03/2014 09:25, Max Leske a écrit :
I do have a version browser for that; but it plays with git at a bit too high level to be as powerfull as you describe.
Is it on Smalltalkhub? Iâd like to take a look if you let me.
It's on github :)
I should have known⦠:)
https://github.com/ThierryGoubier/AltBrowser/tree/pharo3.0/Alt-Browser.packa...
and the git interface lives inside gitfiletree, at:
https://github.com/dalehenrich/filetree/blob/issue_124/repository/Monticello...
Also available via ConfigurationOfGitFileTree.
I'd be especially interested to know if, the way you're planning to do it, will allow to:
- Better track methods among class renames, package renames, ownership in packages and so on: mine I think get the commits for all versions of a method right, but is limited in its ability to find them through renames (since each version path name may be different from the current one).
Ummmm⦠Iâll have to see about that⦠^^ But Iâll definitely let you know.
- And be able to rebuild package version history via the VCS history, as I do now in gitfiletree.
Yes, that is something that should be possible. To be honest, those thoughts are a bit too far in the future at the moment. First, I want to have Git plumbing running, then Iâll see about the rest.
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 07/03/2014 09:52, Max Leske a écrit :
- And be able to rebuild package version history via the VCS history, as I do now in gitfiletree.
Yes, that is something that should be possible.
To be honest, those thoughts are a bit too far in the future at the moment. First, I want to have Git plumbing running, then Iâll see about the rest.
That was certainly the advantage of my solution: easy plumbing, left me the time to: use it, and plan good uses of it. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine. Jan
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial! Alternate implementations to FileTree are welcome! Dale On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
On 06.03.2014, at 23:34, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
How do you sleep at night?? :p
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
Haha, sleep is overrated:) On Thu, Mar 6, 2014 at 2:39 PM, Max Leske <maxleske@gmail.com> wrote:
On 06.03.2014, at 23:34, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
How do you sleep at night?? :p
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
Just for the sake of argument, I also don't like how things are broken down to one file per method and class being that json thing. Looks weird, and makes viewing code on github very tedious. On Fri, Mar 7, 2014 at 12:41 AM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Haha, sleep is overrated:)
On Thu, Mar 6, 2014 at 2:39 PM, Max Leske <maxleske@gmail.com> wrote:
On 06.03.2014, at 23:34, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
How do you sleep at night?? :p
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
On 06/03/14 22:34, Dale Henrichs wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
Lucky you, I still have to wait for this to happen :-) Let's make myself clear, +1 was not because of mercurial, but because of class-per-file on-disk layout. Jan
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz <mailto:jan.vrany@fit.cvut.cz>> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
I'm coming late to this, but Dolphin's VCS format has one file per package and "extensions", and one file per class (instance and metaclass). We succesfuly used that approach with git for more than a year. I know Object Arts did the same but backed by MS VCS (sourcesafe). It is good that we're discussing HOW to version everything with an external file based VCS. That means we'll end up doing it the best possible way. Regards. El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany@fit.cvut.cz> escribió:
On 06/03/14 22:34, Dale Henrichs wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
Lucky you, I still have to wait for this to happen :-)
Let's make myself clear, +1 was not because of mercurial, but because of class-per-file on-disk layout.
Jan
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz <mailto:jan.vrany@fit.cvut.cz>> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
When you invent the next format, keep in mind that cross-platform source code sharing is something to consider as well ... It's always harder to make cross-platform code and some compromises have to be made to accommodate multiple dialects ... Also consider that with FileTree we are only on the first step of Make it work, Make it right, Make it fast ... Put your energy into implementations not arguments:) Dale On Thu, Mar 6, 2014 at 3:09 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
I'm coming late to this, but Dolphin's VCS format has one file per package and "extensions", and one file per class (instance and metaclass).
We succesfuly used that approach with git for more than a year. I know Object Arts did the same but backed by MS VCS (sourcesafe).
It is good that we're discussing HOW to version everything with an external file based VCS. That means we'll end up doing it the best possible way.
Regards. El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany@fit.cvut.cz> escribió:
On 06/03/14 22:34, Dale Henrichs wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
Lucky you, I still have to wait for this to happen :-)
Let's make myself clear, +1 was not because of mercurial, but because of class-per-file on-disk layout.
Jan
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz <mailto:jan.vrany@fit.cvut.cz>> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
This was mentioned a while ago but... As there is not only Smalltalk code in today's projects, Git is nice. And, file per method or not, at this point, we have code in Git and it shows, and it helps the community being more visible. So, I am happy in being able to put my code in git. And git is not only the remote thing, but the local git repository. Which helps with projects and all the kinds of files we need to deal with. All in one place, how nice. Smalltalkhub is cool but not for non Smalltalk files. Phil On Fri, Mar 7, 2014 at 12:24 AM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
When you invent the next format, keep in mind that cross-platform source code sharing is something to consider as well ... It's always harder to make cross-platform code and some compromises have to be made to accommodate multiple dialects ...
Also consider that with FileTree we are only on the first step of Make it work, Make it right, Make it fast ...
Put your energy into implementations not arguments:)
Dale
On Thu, Mar 6, 2014 at 3:09 PM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
I'm coming late to this, but Dolphin's VCS format has one file per package and "extensions", and one file per class (instance and metaclass).
We succesfuly used that approach with git for more than a year. I know Object Arts did the same but backed by MS VCS (sourcesafe).
It is good that we're discussing HOW to version everything with an external file based VCS. That means we'll end up doing it the best possible way.
Regards. El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany@fit.cvut.cz> escribió:
On 06/03/14 22:34, Dale Henrichs wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
Lucky you, I still have to wait for this to happen :-)
Let's make myself clear, +1 was not because of mercurial, but because of class-per-file on-disk layout.
Jan
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz <mailto:jan.vrany@fit.cvut.cz>> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
Just to rephase myself: The fact we're discussing how to store things in git is a HUGE advance in mindset, it means we'll end up versioning on top of it. I said: "That means we'll end up doing it the best possible way." Maybe FileTree is the best possible way that considers all the constraints and requirements you mention :) When you built FileTree/Cypress you were an outlier (in the Smalltalk realm), now it's mainstream. ;-) Regards! -- Esteban 2014-03-06 20:24 GMT-03:00 Dale Henrichs <dale.henrichs@gemtalksystems.com>:
When you invent the next format, keep in mind that cross-platform source code sharing is something to consider as well ... It's always harder to make cross-platform code and some compromises have to be made to accommodate multiple dialects ...
Also consider that with FileTree we are only on the first step of Make it work, Make it right, Make it fast ...
Put your energy into implementations not arguments:)
Dale
On Thu, Mar 6, 2014 at 3:09 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I'm coming late to this, but Dolphin's VCS format has one file per package and "extensions", and one file per class (instance and metaclass).
We succesfuly used that approach with git for more than a year. I know Object Arts did the same but backed by MS VCS (sourcesafe).
It is good that we're discussing HOW to version everything with an external file based VCS. That means we'll end up doing it the best possible way.
Regards.
El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany@fit.cvut.cz> escribió:
On 06/03/14 22:34, Dale Henrichs wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
Lucky you, I still have to wait for this to happen :-)
Let's make myself clear, +1 was not because of mercurial, but because of class-per-file on-disk layout.
Jan
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz <mailto:jan.vrany@fit.cvut.cz>> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
Oh I certainly don't think that FileTree is the best possible way ... as it stands FileTree functions as a bridge that allows folks to migrate towards using git/mercurial/svn ... once a beach head in the git/mercurial/svn world is established it is a good time to re-evaluate what is important... tools integration is probably much more important than the implementation detail of what the packages look like on disk ... but that's just my opinion:) Personally when I am working, the method is the unit of functionality that is important ... so for me the history of method is important information and when I identify a change that is "interesting" i then may want to see all of the other things that changed when that method was changed ... the current implementation of FileTree makes this kind of spelunking possible ... but it takes tools to bring this to reality ... Are there other ways to make this a reality? ... I'm almost certain that there are ... but perhaps this functionality is only important to me ... or perhaps there are better ways of looking at the whole problem ... or ??? I have a vision for where FileTree and tools built upon it are headed but I won't claim that my vision "the one true way"... I've said this about Metacello for years: "I can hardly wait until someone implements a replacement for Metacello" ... and I feel the same way about FileTree:) I encourage other folks to implement their own visions... This is evolution in action ... stand on the shoulders of FileTree and build something better ... stand on the shoulders of git and build something better ... Dale On Thu, Mar 6, 2014 at 5:09 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
Just to rephase myself: The fact we're discussing how to store things in git is a HUGE advance in mindset, it means we'll end up versioning on top of it.
I said: "That means we'll end up doing it the best possible way."
Maybe FileTree is the best possible way that considers all the constraints and requirements you mention :)
When you built FileTree/Cypress you were an outlier (in the Smalltalk realm), now it's mainstream. ;-)
Regards!
-- Esteban
2014-03-06 20:24 GMT-03:00 Dale Henrichs <dale.henrichs@gemtalksystems.com
: When you invent the next format, keep in mind that cross-platform source code sharing is something to consider as well ... It's always harder to make cross-platform code and some compromises have to be made to accommodate multiple dialects ...
Also consider that with FileTree we are only on the first step of Make it work, Make it right, Make it fast ...
Put your energy into implementations not arguments:)
Dale
On Thu, Mar 6, 2014 at 3:09 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
I'm coming late to this, but Dolphin's VCS format has one file per
package
and "extensions", and one file per class (instance and metaclass).
We succesfuly used that approach with git for more than a year. I know Object Arts did the same but backed by MS VCS (sourcesafe).
It is good that we're discussing HOW to version everything with an external file based VCS. That means we'll end up doing it the best possible way.
Regards.
El mar 6, 2014 7:51 PM, "Jan Vrany" <jan.vrany@fit.cvut.cz> escribió:
On 06/03/14 22:34, Dale Henrichs wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
Lucky you, I still have to wait for this to happen :-)
Let's make myself clear, +1 was not because of mercurial, but because of class-per-file on-disk layout.
Jan
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz <mailto:jan.vrany@fit.cvut.cz>> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses
are
in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
LOLWAT! :D for what is worth, my experience.. I donât know mercurial and I was ~8 months flirting with git and in a relationship since ~4 Git is okay Exposing the code out there in a way others can use their familiar commands to test our software is something I find very healthy But for us, automation is the real winner and git kind of helped with it (not that is a total requisite, but it was a way to have both âprofitsâ in one move) On Mar 6, 2014, at 7:34 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
My dream has finally come true ... Smalltalkers arguing the merits of git vs. mercurial!
Alternate implementations to FileTree are welcome!
Dale
On Thu, Mar 6, 2014 at 2:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
+1. In St/X I do exactly the same. Works just fine.
Jan
I hope that somebody will have a look at the newspeak library that abstract from the back-end storage because this is an interesting idea.
On Thu, Mar 6, 2014 at 12:18 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote: Stephan,
The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis.
the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks.
But why do you need command-line diff tools? If one spends most of one's time in Pharo why not have diff tools there-in and avoid all these contortions to appease a primitive VCS? You're already hitting thins like filename length limits in the mapping, and you're hitting performance problems.
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ...
So you can use "blame" to view a line by line history of the method modifications ...
If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ...
Dale
On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan@stack.nl> wrote: Max wrote
In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.
Iâm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that leads to another set of problems.
My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest?
Stephan
-- best, Eliot
On 07.03.2014, at 08:38, Pharo4Stef <pharo4Stef@free.fr> wrote:
I hope that somebody will have a look at the newspeak library that abstract from the back-end storage because this is an interesting idea.
Noted.
On Thu, Mar 6, 2014 at 12:18 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote: Stephan,
The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis.
the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks.
But why do you need command-line diff tools? If one spends most of one's time in Pharo why not have diff tools there-in and avoid all these contortions to appease a primitive VCS? You're already hitting thins like filename length limits in the mapping, and you're hitting performance problems.
The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO.
At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ...
So you can use "blame" to view a line by line history of the method modifications ...
If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ...
Dale
On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan@stack.nl> wrote: Max wrote
In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.
Iâm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that leads to another set of problems.
My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest?
Stephan
-- best, Eliot
On 6 March 2014 20:18, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Stephan,
The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis.
At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ...
So you can use "blame" to view a line by line history of the method modifications ...
If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ...
Another huge strength with versioning per method (and one of the main reasons I don't complain too loudly about the uselessness of GitHub in viewing code when doing this) is also that you never ever have to try merge two methods that two different commits have put in the same place, and the diff algorithm has decided to _interleave_ the methods. Fun times! frank
Dale
On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Max wrote
In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.
Iâm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I donât want to suggest switching to a larger granularity, as that leads to another set of problems.
My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest?
Stephan
Frank, Yeah, for browsing Smalltalk repos on github itself, I figured that an Amber app would be the way to go ...then you could have a "real" code browser with senders implementers, etc.... and the same code could run in a pharo image to browse unloaded repos from github or disk ... Just a simple matter of putting tooling in place:) Dale On Fri, Mar 7, 2014 at 1:34 AM, Frank Shearar <frank.shearar@gmail.com>wrote:
On 6 March 2014 20:18, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Stephan,
The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis.
At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ...
So you can use "blame" to view a line by line history of the method modifications ...
If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ...
Another huge strength with versioning per method (and one of the main reasons I don't complain too loudly about the uselessness of GitHub in viewing code when doing this) is also that you never ever have to try merge two methods that two different commits have put in the same place, and the diff algorithm has decided to _interleave_ the methods. Fun times!
frank
Dale
On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Max wrote
In my opinion there are other factors, like readability, maintenance
etc,
that are maybe more important than speed.
I'm not totally convinced. The readability from the outside is limited by having one file per method. Mainstream tooling assumes one file per class. The emails from github to this list are a good example of the usability problems that leads to. I don't want to suggest switching to a larger granularity, as that leads to another set of problems.
My point was more if we could mostly avoid the source view, and directly work with the archive. Why is working with single files fastest?
Stephan
participants (12)
-
Dale Henrichs -
Eliot Miranda -
Esteban A. Maringolo -
Frank Shearar -
Goubier Thierry -
Jan Vrany -
kilon alios -
Max Leske -
Pharo4Stef -
phil＠highoctane.be -
Sebastian Sastre -
Stephan Eggermont