Suppress Credit

Greetings all,

When a method is changed, the Browser records certain statistics such as author initials and
date. Usually, this is appropriate.

However, when porting code, the only change to many methods is to convert crlf to nl.
Changing author initials and date for something this insignificant is not appropriate and
destroys important historical data. Where is the method(s) implementing this behavior? I
would like to avoid this change or be able to revert it in specific cases.

 - Dan

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Dan,

On 4/13/2015 4:41 PM, Dan Norton wrote:
What I usually do is to open a File List in Cuis, point to the file,
select it (do 'get entire file' if it is too big). Then, on the bottom
pane, alt-a, alt-shift-u, alt-s. Sometimes I also remove some extra
blank space or reformat a bit, etc.

Only then, file in the code.

Sometimes, I want to clarify a bit a method comment or such, but do not
want to modify the stamp. Then, I file out the method, edit it in the
File List, and then file in again.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

It would be neat to keep around some history about authors. It's always bugged me that we only keep around information about the person who most recently touched a method.

Maybe that's too much baggage to carry around, but I think history might be worth it.

Just a thought. Shoot holes in it.

--C

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

I think that is a good idea. Besides, keeping the history of each method
as we do today is not enough. Deleted methods have no history. There's
no link between methods that got keywords/arguments added or removed
(and one is the replacement of the other). There is no history of class
shapes, etc. On top of that, we drop all history at rather arbitrary
points in time (#condenseSources).

Definitively an area where improvements would be welcome!

OTOH, we are kind of following the conventional trend towards using Git
(or similar) for versioning, and version agnostic dev tools. So, there
is a tension there, and I don't see a clear, consistent and simple path.

Folks, please lets discuss this. We need ideas.

Cheers,
Juan Vuletich

On 4/15/2015 8:34 PM, Casey Ransberger wrote:

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

On Sat, 2015-04-18 at 09:53 -0300, Juan Vuletich wrote:
> I think that is a good idea. Besides, keeping the history of each method
> as we do today is not enough. Deleted methods have no history. There's
> no link between methods that got keywords/arguments added or removed
> (and one is the replacement of the other). There is no history of class
> shapes, etc. On top of that, we drop all history at rather arbitrary
> points in time (#condenseSources).
>

The history for deleted classes/methods exist in git.

> Definitively an area where improvements would be welcome!
>
> OTOH, we are kind of following the conventional trend towards using Git
> (or similar) for versioning, and version agnostic dev tools. So, there
> is a tension there, and I don't see a clear, consistent and simple path.
>
> Folks, please lets discuss this. We need ideas.
>

It would be great to see Cuis continuing on the course it has been on
since moving to git: use git and related tools for all things
version/history related.  Think of the image as the source of the
present and very recent history via changes.  Extract any needed
historical data from the repos, rather than the image for analysis and
reporting.  There are a large number of tools that exist to analyze
repositories and it would make more sense to try to leverage those than
reinvent them.

It would be great if we had a set of tools that could extract relevant
information from the git repos (and if needed, the Cuis packages
committed there) to feed existing Smalltalk tools like Moose, Code City,
etc. as well as other (non-Smalltalk specific) tools such as Gource.
It's unlikely that any of us would have the time or inclination to
reproduce any one of these tools for Cuis let alone several of them, so
why try?  Seems more productive to leverage what already exists...



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org