[cvsnt] CVSNT to CVS

[Arthur Barrett]

Andreas,

> > policy implementation).  If the corporate policy is to NOT allow you
> > access to write that file - then that's the policy.
> 
> That's why I need to find someone else who is able and can be
> convinced to do the commit for me. 

That is just circumventing the policy.  

An auditor finding that this happened would fail the process and any
company using this process would lose accreditation.

We go though this in our CM Design course: what you are attempting to do
in an unmanaged way should be managed by the CM tool and CVSNT has all
the functions necessary to manage it.  For instance: you can check in,
but then a person with seniority is responsible for promoting the change
from 'dev' to 'approved' (or 'code review).  

> If I'm not allowed to commit a change,
> that does not mean that it is forbidden that I pass on
> the change to another person who is allowed, and the tool
> should enable me to do so.

If you were authorised then you would be authorised ;)

This is a fantastic example of the difference of thought processes
between a project manager and a programmer.

A programmer thinks it can be solved with a program, a manager looks for
how it can be better managed or if it is intentionally unmanageable.

Saying that your employer has refused to give you write permission to a
file but it is OK to author a change and give that change to someone
else who does have permission to write is like saying that I don't have
permission to keep this DVD I rented from blockbuster but I can always
just duplicate it and keep the copy: of course it's technically
possible, but I am not authorised.

> Where is that bleeding edge? So far I failed to notice anything
> like research in that area. 

You need to read CM articles and journals and newsgroups that are not
about specific tools but about CM theory and generic implementation.

> We have used cvs and then cvsnt, and started to think seriosly about
> switching to svn two years ago, and then still waited until svn 1.5
> came out -- we didn't want to do without merge support. 

If the migration of the 'legacy' CVSNT system to SVN has not delivered
all the expected BENEFITS but you have still obtained all the COSTS of
migration then it's likely been an expensive exercise, though based on
an article on the valuation of IT assets published in The Financial
Times UK Edition 36,501 on Monday October 1 2007 it is likely your
organisation hasn't measured those costs. The article talks about the
lack of business cases for the benefit of software and also the business
case for maintaining legacy assets - you may want to obtain a copy or of
the full whitepaper.  

What has your employer learnt about valuing your IT assets (like CVSNT)
and how to perform a risk assesment and cost benefit assesment about
migrating from legacy systems in the future?  

In short - I know you think GIT is great, but presumably you also
thought SVN was great before you began a wholesale migraion.  What
planning process are you putting in place to ensure that exactly the
same thing doesn't happen when you migrate from SVN to GIT?  All the
COSTS but not the BENEFITS?  This is why we wrote EVS, this is it's
justification: one system - many workflows - open clients.

I'm interested to know why your organisation thought about switching (to
SVN) at all?  What tangible measurable benefit did you expect to gain?
When you realised that the benefit wasn't there (which I'm assuming
based on comments in this thread) did you do (stop and return to
CVSNT?)?  

Regards,


Arthur Barrett