[MonoDevelop] UML docs on VersionControl
Daniel J. Lauk
dj at djlauk.de
Sat Jul 9 15:13:57 EDT 2005
Thanks for your response and offer.
Basically, I wanted to start hacking on the libraries and add support
for CVS later on. The UML diagrams are supposed to support, if I may use
your term :-) , "library hackers" in future maintenance of it.
By the way: Do you still actively maintain VersionControl? I wouldn't
want to get in your way or so. I slipped into it by the Google "Summer
of Code" program. (Project proposal was "SVN integration in MD". I got
rejected, still liked the idea and now I populate the 'net with UML...)
Back on the UML diagram track. Actually, I wanted to have two or three
levels of UML diagrams.
The one I'm currently working at is a general view from ... hmmm... I
guess 1 to 5 km over ground :-)
Its purpose is plainly to help associate class names (and the implied
responsibilities) to certain domains (projects / files).
The next step for me would have been to go to what you called the
"middle level" and diagram how SubversionVersionControl works.
I am not sure, if there would be any reason to model the low level. I
mean it is well documented in a notation, commonly known as C# ;-)
So, errm, just drop me a line or two, what you think.
Joshua Tauberer wrote:
> Nifty, Daniel. I've never had anyone UML diagram my classes before. :)
> You should keep in mind that there are basically three levels to the
> library, and a user of the library probably is going to be only
> interested in one.
> At the top level is the VersionControlSystem class, abstracting over
> the different types of version control. There's not much to diagram
> here, although an explanation of what the related classes are supposed
> to represent is in order. Users of the library should be looking at
> this class and the related classes in VersionControl.cs, and they
> don't really need to know about the others.
> At the middle level is SubversionVersionControl, the implementation of
> VersionControlSystem for Subversion. Only library hackers should ever
> care (or know) about this class.
> At the lowest level there is the SvnClient class that very simply
> wraps the p/invoke library calls to the Subversion API. In
> principle, no one should ever use this class (and the classes defined
> in it) because it's merely there to support the middle level. Again,
> the only people that need to know about the class are library hackers
> specifically working on improving Subversion support.
> So, my suggestion would be to not UML all of the classes together.
> But if you have any questions about how anything in the library works,
> drop me an email.
More information about the Monodevelop-list