[Building Sakai] WHAT HAPPENED TO SERVER-CONFIGURATION-SERVICE ?!?
Zach Thomas
zach.thomas at gmail.com
Tue Sep 13 17:08:37 PDT 2011
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"
More information about the sakai-dev
mailing list