[cvsnt] CVSNT to CVS

[Arthur Barrett]

Andreas/Peter/Tony,

It's good to see some technical discussion about EVS (and a GIT layer)
however the conversation really belongs on the EVS newsgroup.  The
problem with having it here is that it'll be difficult to find in a
years time, and people who've subscribed to the EVS newsgroup because
they are interested in new layers (like a Git layer) are missing out on
contributing to the discussion...

Even the title of this thread is innapropriate...

Here follows some (mostly non-technical) observations.

> And yes the are all the same, at heart.  That's the depressing thing 
> about it.. they all go off writing new ones instead of 
> improving what's there already and end up with something that is 
> basically the same thing with a new skin on it.

Many people do not realise just HOW SIMILAR these systems are even when
the resulting workflow is quite different; however it does highlight
just how wedded to a single workflow people can become that for someone
else to use a different workflow they feel the need to rewrite the tool
from scratch.  This is what led to CVSNT forking from CVS: a couple of
small changes to enable a new workflow were rejected as possible changes
to CVS 1.10...

If you spend a lot of time offline (like on a train) then you can
already achieve an identical workflow to Git by using CVSNT 2.5.04 and a
local proxy (ok - it wont allow you to commit while offline, but the
next version of EVS would even let you do that).  


> Users are picky about the tools they use, and many (perhaps 
> most) are very unhappy about going outside their comfort 
> zone.  

Rather than people being 'pretty indifferent to switching tools' (as
someone wrote in this thread) we find it almost like a dark-ages
mediaeval religious battle.  People fight tooth and claw to use their
preferred client - though usually expressed as a desire to install a
server: SVN or CVS or GIT when all they really care about is a
particular defined workflow/client.

> give them a list of old and new commands, and that's it.

Far from it - but it's not 'resistance to change' it's fashion.  A
percentage of people want to use the latest toy, no matter the benefit;
they wanted to use SVN last year and GIT this year, YouTube one year and
facebook the next and are currently off twittering somewhere.
Enterprises want to attract these talented people but need to keep a
sane and centralised change management system - which is why it was
worth writing EVS.


> I think this is the important part. DVCSes suddenly open styles
> of collaboration that previously simply impossible.
.
.
.
> That's the actual wonderful thing about git and the other DVCSes:
> I would just clone, say, the cvsnt repo, and work on some features,
> and I can do so under version control. When I'm done I can just tell
> you to pull it back -- no need for committer status or nothing.

A lot of people blame *tools* when the reason for certain limitations is
*policy*.

Andreas' example of being able to change a file he doesn't have access
too is NOT a failure of the tool - it's a policy failure (or at worst
policy implementation).  If the corporate policy is to NOT allow you
access to write that file - then that's the policy.  If the corporate
policy is to allow one person to write to the repository on bahalf of
another person then that is the policy (different 'username' to 'author'
-  EVS and CVS Suite both have this feature).

EVS is capable of 'impersonating' other SCM servers like CVS, SVN, TFS
and one day others probably including GIT - however there will be
(potentially large) operational differences because of POLICY.  If the
corporate policy is to prevent writes to the revision history where
username is different to the author then it will be disallowed
regardless of the client tools' support for that feature.  Note: if you
make the change then it is your change not someone elses and the SCM
tool would be failing basic audit checks if it did not record that.

CVSNT (and other 'free' SCM systems) have frequently benefited from this
- it's a two edged sword - often a company will have ClearCase as their
SCM system and have all the policies implemented, however someone
doesn't like the POLICY and blames the TOOL and so covertly installs
CVSNT so they control their own policy.  Whilst this helps the profile
of our project it is a fundamentally flawed approach to SCM and to
employment.

I've also seen plenty of cases where a commercial SCM system is
implemented with arbitrary policies that unnecessarily hamper the
efficiency of the team.

Too many people confuse TOOL with POLICY, ie: This tool wont let me do
xyz; when it's: The corporate policy is not to do xyz.  The best
question to ask is: is this a valid policy - should it be changed?

To me GIT (and similar tools) has a fundamental flaw (for commercial
software development).  In Intellectual Property and Copyright law cases
for software the only line of defense that a company has is to show
unique parallel invention - ie: that the feature was invented and
implemented not 'copied'.  If a developer does all of their 'small'
changes on their 'own' repository then push up just the 'result' then
leave and take their 'own' repository with them (or it's lost or
deleted) then there is no way to defend spurious claims in court.

Or a far simpler problem: the laptop is left on a train and the local
repository hasn't been 'pushed' back to a master repository for a few
days/weeks/months...

> Looked into darcs? As far as I heard they can record variable 
> name changes as such.

I don't know darcs at all, but I think this feature is similar to the
'property' feature of SVN which CVSNT has had for years and years and
now EVS has it too.

> evs has more fine grained object tracking than any system 
> currently out there (that I've seen) and at the same time 
> can represent changes at the repository level if required.  

The real bleeding edge of SCCM is line/block revision control so that
the SCCM system can identify that all these projects have about()
functions, and these are the variations to them; that all these word
docs have these 'limitation of liability' paragraphs and these are the
variations to them - and indeed to be able to arbitrarily 'merge' or
'replace' them all.  All tools I know of are currently file based, not
block based - and we even discussed doing this with EVS however it was
(wisely) decided that we'd already tasked ourselves with a big enough
problem...

Regards,


Arthur Barrett