Re: (FC-Devel) Further OCD comments regarding CVS

["Chris M. Moore +44 (0)1705 701701 ext 1999" <chris.m.moore@gecm.com>]

> Hi, Chris!

Hi Andrey,

> >>>>> "CMM" == Chris M. Moore  writes:
> 
> CMM> Hi peeps, Yes its me again.  I've had some thoughts on what the OCD
> CMM> implies to usage of CVS and the CORBA UML interfaces.  It seems to me
> CMM> that the OCD documents repository _is_ a CVS repository and that the
> CMM> CORBA UML interfaces are what the tools see on the client side.  (One of
> CMM> the tools would be a GUI to manipulate the client side sandbox copy).
> CMM> Is this what you intended Andrey?
> 
> Yes, this is the implementation, I've thought about while writing the
> document.  It's implied but by no way it is required by OCD as is.

OK, we're on the same wavelength.  I think. :)
 
> CMM> If this is the case then I would like to suggest that the CVS repository
> CMM> is optional.  There will definitely be a need for an administrator if
> CMM> CVS is used (merging problems, passwords etc) and this extra
> CMM> overhead/complexity may be off-putting for small projects (or even large
> CMM> projects at startup when there is considerable creation of new objects
> CMM> eg. two developers independantly create the objects with the same name).

I've had further thoughts on this and I can now only justify this in the case of
lone developer or student(s) on small projects.  Whiteboard mode just isn't
enough to allow developers the flexibility to try out what-if scenarios.

> CMM> This would leave the OCD documents client talking to multiple UIs (the
> CMM> client becomes the server!).  The UIs would/should operate in whiteboard
> CMM> mode ie. if another user creates an object, it appears on your screen.
> CMM> The client would save its contents in some human readable text format so
> CMM> that CVS can be used for version control if required.
> 
> CMM> Hows this sound to you?
> 
> Uhh....   This is exactly what I've listed in <q/Alternatives and
 > trade-offs considered/:
> 
>               Every developer or group of developers keeps their own
>               copy of repository.
>               <lb>
>               <emph>Reason to decline:</emph> Difficult and error
>               prone synchronization between repositories.

Don't follow.

> Imagine the following.  We've produced the first snap of FreeCASE
> implementing your idea.  Now, I'm working at home in Kiev, Ukraine.  You're 
> working in <traceroute check> yes, UK.  I can't afford being 100% time
> online (got only 1 phone line).  We're making _different_ changes in the
> same model.  Now, the questions:
>   1. Whose model is right?
>   2. When and how you'll get mine changes?
>   3. When and how I'll get your changes?
>   4. How they should be merged?

In this case CVS would be the best solution.  I was confused by Sami's OO-layer
over CVS bit which you agreed with.  But now I think our ideas are very similar
ie. CVS repository + CORBA interfaces + tools (CORBA 3-tier client server
architecture!).  My only extension is optional nature of CVS repository to
reduce burden on projects which do not merit the overhead.

> Besides, maintaining small CVS repo is not that difficult.  It took me
> about 30 minutes to skim trough the manual to initialize it and make first
> experiments (and that was *too* much).

I hope by this that you mean to hide the CM tool behind some generic GUI based
interface which would be configurable to use with any command line based CM
tool.  I could go for that.  :)  If you mean we should pick one CM tool and base
our implementation of FreeCASE around that then I strongly disagree.

> Additionally, I haven't seen any
> merge problems during 2.5-year cvs usage.

We see lots of merge conflicts.  I guess it is a function of how well your team
works. :(

Chris Moore