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

Tue Sep 13 15:52:24 PDT 2011

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> 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> 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> 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
> >>>>
> >>>> 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
> >>>>
> >>>> 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
> 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"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110913/c6f458f4/attachment.html 