[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (FC-Devel) Further OCD comments regarding CVS
- To: email@example.com
- Subject: Re: (FC-Devel) Further OCD comments regarding CVS
- From: "Chris M. Moore +44 (0)1705 701701 ext 1999" <firstname.lastname@example.org>
- Date: Mon, 19 Apr 1999 15:23:17 +0000 (GMT)
- Autoforwarded: false
- Disclose-Recipients: prohibited
- Hop-Count: 2
- Importance: normal
- Mr-Received: by mta ADVAX1.MUAS; Relayed; Mon, 19 Apr 1999 15:23:17 +0000
- Mr-Received: by mta ADVAX1; Relayed; Mon, 19 Apr 1999 15:23:18 +0000
- Mr-Received: by mta GCSCHM; Relayed; Mon, 19 Apr 1999 15:23:40 +0000
- Sender: email@example.com
- Sensitivity: Company-Confidential
- Ua-Content-Id: 11D49BD70F00
- X400-Mts-Identifier: [;9517231519041999/A09427/ADVAX1]
> Hi, Chris!
> >>>>> "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.
> <emph>Reason to decline:</emph> Difficult and error
> prone synchronization between repositories.
> 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