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

[Andrey V Khavryutchenko <akhavr@compchem.kiev.ua>]

Hi, Chris! 

>>>>> "CMM" == Chris M Moore  writes:

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

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

Ok, let me explain further.  Repository access should now be necessary if
you're not going to use version management functions (I'll add this to the
document).  As soon as you're going to use some multiuser or version
features you *shall* need the single repository to be able to synchronize
with something.

Setting local only cvs repository is the matter of running 'cvs --init' and 
setting CVSROOT.

[...]

>>  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.

CMM> Don't follow.

I've tried to explain this in the following:

>> 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?

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

I think it would help us to agree fully with each other if we will
substitute every use of 'CVS' with 'version management tool', won't it?

>> 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).

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

You'll be working with your FreeCASE application, which will access
FreeCASE Repository.  You shouldn't even know that there is CM repository
somewhere.  The exact choise of CM tool will be made by FreeCASE Rep
admin.  Some common cases (like CVS repository) could be prepackaged.

Agreed?

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

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

Well, by the moment, the I'm the only live being in my team ;)  Guess, this 
is the matter of laying out version management guidelines _before_ giving
access to the repository.

-- 
SY, Andrey V Khavryutchenko	http://www.kbi.kiev.ua/~akhavr
Freelance Software Engineer

Shick's Law:
	There is no problem a good miracle can't solve.