[Building Sakai] WHAT HAPPENED TO SERVER-CONFIGURATION-SERVICE ?!?

Ray Davis ray at media.berkeley.edu
Wed Sep 14 08:33:15 PDT 2011 

By the way, formatting issues aside, one-step svn blame and git blame 
won't necessarily tell me what I want to know after (perfectly 
legitimate) refactoring or project restructuring. On such occasions, I 
dance a good ol' country music Two-Step: go to the commit before the 
refactoring commit, and do a "blame" from there.

Best,
Ray

On 9/14/11 5:37 AM, Jim Eng wrote:
> Thanks, Zach.  That helps.  I will have to remember to add "-x -w" when using "svn blame" to track down an issue.   Without that, it looks like the entire ServerConfigurationService interface except the copyright notice and imports may have been added in commits 98145 and 98146.
>
> It's amazing how much of the ServerConfigurationService interface goes back to commit 1.
>
> Jim
>
>
> On Sep 13, 2011, at 8:08 PM, Zach Thomas wrote:
>
>> Try svn blame -x -w<some file>
>>
>> The history is not lost, just obscured (which should be avoided when possible).
>>
>> Zach
>>
>> Sent from my iPhone
>>
>> On Sep 13, 2011, at 6:37 PM, Ray Davis<ray at media.berkeley.edu>  wrote:
>>
>>> I'm not going to touch the question of what a project should adopt as
>>> its formatting rules, or how a project should choose to enforce them --
>>> those vary wildly from project team to project team. But I can testify
>>> that my sanity would be even more frayed than it is if it wasn't for the
>>> existence of Subversion and Git front-ends that can ignore whitespace
>>> changes when viewing diffs. (Recent versions of Git even support a
>>> whitespace flag for "git blame", which is pretty awesome of them.) Such
>>> clients don't change the rules, and don't change the enforcement, but
>>> FWIW they can somewhat ease the pain.
>>>
>>> Best,
>>> Ray
>>>
>>> On 9/13/11 4:16 PM, Jim Eng wrote:
>>>> But the problem is that people have created the codebase using many
>>>> different coding styles. If a developer decides to reformat the file,
>>>> all of the history is lost. So we want NOT to reformat any of the files.
>>>> We do not want to adopt a consistent style at this point and reformat
>>>> everything because that will lose the history of all of the files that
>>>> get reformatted.
>>>>
>>>> It is well-known in the sakai community that we do not reformat files
>>>> like has been done here. I had this discussion with Aaron Z a couple
>>>> years ago and did not allow some changes to be merged into the content
>>>> module until he removed the reformatting that would have destroyed the
>>>> history of several classes. It was stated very clearly in early
>>>> equivalents of the bootcamps led by Glenn Golden and others, one or two
>>>> of which were attended by Aaron Z.
>>>>
>>>> My point here is that this is not usually a problem as long as people
>>>> abide by the community norms. Unfortunately, the cost is high when a
>>>> senior, valued and respected developer with wide-ranging commit
>>>> privileges decides to trash the history in this way.
>>>>
>>>> If Matthew is correct about there being no way to recover that history
>>>> in this case, there's not much we can do. If this was done by a newer
>>>> developer, we might consider revoking commit rights until the developer
>>>> in question agrees to abide by the community norms. I don't think that's
>>>> appropriate here.
>>>>
>>>> Jim
>>>>
>>>>
>>>> On Sep 13, 2011, at 6:52 PM, Matthew Jones wrote:
>>>>
>>>>> The problem is that even if they were 'reverted' as far as subversion
>>>>> is concerned the formatting changes will always be there because
>>>>> future versions depend on past versions. There is no svn obliterate
>>>>> that has been implemented. [1] You can't 'remove' a commit in
>>>>> subversion without:
>>>>>
>>>>> - Shutting down the repo
>>>>> - Doing an svnadmin dump on the repo
>>>>> - Loading the repo while filtering out this commit (with something
>>>>> like svndumpfilter) [2]
>>>>>
>>>>> This process with ~100K commits would easily take a *very long time*.
>>>>> This is typically only reserved if for *critical* issues like if a
>>>>> high profile password or some restricted software "accidently" got
>>>>> checked into the repo.
>>>>>
>>>>> I agree that it's a bummer that we don't have any enforcement on
>>>>> formatting rules, and this was actually something that Chris Maurer
>>>>> talked about today. There are many suggestions here [3] and they seem
>>>>> to boil down to 3 things
>>>>>
>>>>> 1) Forcing developers to all adhere to the same formatting standards
>>>>> (unlikely in an open community)
>>>>> 2) Applying an svn pre-commit hook to auto format based on some rules
>>>>> that some group decides is best (problem with this is it could change
>>>>> immediately committed code, resulting in users immediately having to
>>>>> run updates after commits)
>>>>> 3) Denying commits in a pre-commit hook if the formatting of the file
>>>>> is not correct (possibly a better idea, but still might make people
>>>>> grumpy!)
>>>>>
>>>>> I'm not sure if any of these would avoid an all caps email subject
>>>>> message in the future though. ;)
>>>>>
>>>>> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=516
>>>>> [2]
>>>>> http://svnbook.red-bean.com/en/1.2/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svndumpfilter
>>>>> [3]
>>>>> http://stackoverflow.com/questions/1017953/svn-automatic-code-formatting-on-check-in
>>>>>
>>>>> On Tue, Sep 13, 2011 at 6:31 PM, Jim Eng<jimeng at umich.edu
>>>>> <mailto:jimeng at umich.edu>>  wrote:
>>>>>
>>>>>    I am still asking that these two commits be backed out and
>>>>>    reimplemented without reformatting parts of the files that do not
>>>>>    need to be changed. If you do not want to do that, please say so,
>>>>>    and I will ask for a vote.
>>>>>
>>>>>    This pattern of reformatting an entire file when making a few
>>>>>    changes is unacceptable, IMO.
>>>>>
>>>>>    Jim
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    On Sep 13, 2011, at 6:23 PM, Aaron Zeckoski wrote:
>>>>>
>>>>>> I think you are thinking of the use of private inner classes in
>>>>>> implementations. This was a pattern that was popular with Glenn and
>>>>>> others and it made things (like services) very difficult to test
>>>>>> because the private classes were inaccessible and had to be
>>>>>> reimplemented in order to do simple tests. Public classes whether
>>>>>> inner or otherwise are generally no problem unless they are final
>>>>>> (this is a hibernate pattern that is very annoying).
>>>>>> If you check in the utils area you will find that I included basic
>>>>>> implementations of the interfaces to make it even easier to use them
>>>>>> (without requiring developers to create their own implementations to
>>>>>> perform simple operations).
>>>>>>
>>>>>> -AZ
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 13, 2011 at 6:11 PM, Jim Eng<jimeng at umich.edu
>>>>>    <mailto:jimeng at umich.edu>>  wrote:
>>>>>>> It turns out that I was having problems due to stale artifacts
>>>>>    in my local maven repo. That was causing problems finding the
>>>>>    inner interfaces. I would have had the same problem even if they
>>>>>    were not inner classes. That's fixed.
>>>>>>>
>>>>>>> I use inner classes in some places. But people had lots of
>>>>>    problems with the inner Storage interfaces in Service classes when
>>>>>    trying to create mocks in the early days of sakai2. Maybe I was
>>>>>    wrong when I said you complained about that. For a while there was
>>>>>    general agreement not to use inner interfaces because of those
>>>>>    problems. Apparently those days are gone.
>>>>>>>
>>>>>>> I am still asking that these two commits be backed out and
>>>>>    reimplemented without destroying the history of the code.
>>>>>>>
>>>>>>> Please.
>>>>>>>
>>>>>>> Jim
>>>>>>>
>>>>>>>
>>>>>>> On Sep 13, 2011, at 5:55 PM, Aaron Zeckoski wrote:
>>>>>>>
>>>>>>>> I'm unaware of issues with inner class interfaces. Please explain.
>>>>>>>> Thanks
>>>>>>>> -AZ
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Sep 13, 2011 at 5:53 PM, Jim Eng<jimeng at umich.edu
>>>>>    <mailto:jimeng at umich.edu>>  wrote:
>>>>>>>>> Aaron, and all:
>>>>>>>>>
>>>>>>>>> Yes, I am shouting!
>>>>>>>>>
>>>>>>>>> It looks like two checkins were made to
>>>>>    ServerConfigurationService recently, but I cannot tell what has
>>>>>    changed because the entire contents of the interface was replaced
>>>>>    though it looks like many of the methods did not change at all.
>>>>>    That means all history for that file is gone. Or maybe I should
>>>>>    say useless. We can no longer do a simple svn command to find out
>>>>>    when a particular line of code changed and why. It looks like
>>>>>    every single line of code except for the interface name changed in
>>>>>    rev 98010.
>>>>>>>>>
>>>>>>>>>
>>>>>    http://source.sakaiproject.org/viewsvn/kernel/trunk/component-manager/src/main/java/org/sakaiproject/component/api/ServerConfigurationService.java?r1=66281&r2=98010&pathrev=98098
>>>>>    <http://source.sakaiproject.org/viewsvn/kernel/trunk/component-manager/src/main/java/org/sakaiproject/component/api/ServerConfigurationService.java?r1=66281&r2=98010&pathrev=98098>
>>>>>>>>>
>>>>>>>>> Then a few more changes were added in rev rev 98098.
>>>>>>>>>
>>>>>>>>>
>>>>>    http://source.sakaiproject.org/viewsvn/kernel/trunk/component-manager/src/main/java/org/sakaiproject/component/api/ServerConfigurationService.java?r1=98010&r2=98098&pathrev=98098
>>>>>    <http://source.sakaiproject.org/viewsvn/kernel/trunk/component-manager/src/main/java/org/sakaiproject/component/api/ServerConfigurationService.java?r1=98010&r2=98098&pathrev=98098>
>>>>>>>>>
>>>>>>>>> I looked this up because I am trying to update a mock in a
>>>>>    contrib project, and someone has added inner interfaces to
>>>>>    ServerConfigurationService, which I am having difficulty dealing
>>>>>    with. I thought we learned the problems with inner interfaces a
>>>>>    long time ago, and I seem to remember Aaron Z complaining about
>>>>>    the problems they created when implementing mocks.
>>>>>>>>>
>>>>>>>>> I think revs 98010 and 98098 should be backed out until they
>>>>>    are cleaned up. The code should NOT be reformatted in this way
>>>>>    that loses all of the history and masks the actual changes that
>>>>>    are being made. The inner interfaces should be moved out so they
>>>>>    are separate interfaces. etc.
>>>>>>>>>
>>>>>>>>> Please.
>>>>>>>>>
>>>>>>>>> Jim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>>>
>>>>>>
>>>>>
>>>>>    _______________________________________________
>>>>>    sakai-dev mailing list
>>>>>    sakai-dev at collab.sakaiproject.org
>>>>>    <mailto:sakai-dev at collab.sakaiproject.org>
>>>>>    http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>
>>>>>    TO UNSUBSCRIBE: send email to
>>>>>    sakai-dev-unsubscribe at collab.sakaiproject.org
>>>>>    <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org>  with a
>>>>>    subject of "unsubscribe"
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>
>
>

More information about the sakai-dev mailing list