[cvsnt] Betr.: CVSNT to CVS

[Tony Hoyle]

Andreas Krey wrote:
> It comes close to the best thing since version control in general, IMHO.
> That way I can basically do everything offline, even complicated merges,
> and only need a connection for pushing back the results. I first considered
> it overkill just as well but then the whole git repository is typically
> smaller than all the 'pristine copy' files that svn puts in the sandbox.

Only for a new repository.  Try pulling down something like redhat, for 
example.

If you're working on the same data all the time then there's saving - 
for an initial download of data you're avoiding a lot of the small ones 
later (although of course you still need to update from the server to 
get others changes, and commit to the server to send your changes, so 
it's debatable how much you're actually saving).  If you're only on a 
project for a short period it's a huge waste especially if it's 
happening remotely.

> With git you would just as well have an 'official' repo, but the funny
> thing is that every developer has a full backup. :-) What's more
> important to me is that I can continue working even when the
> central server is offline (like 'powered down for holidays').

Something we considered adding to cvsnt is offline commits, so you could 
commit locally then sync later.  It's not really a common case though - 
it's rare you don't have *some* internet connectivity.

> That's the point I was tring to make: EVS can't come to a point where
> it mimics a git server so that you can treat it like one in all regards.

Under normal use you wouldn't be able to tell the difference.  You're 
talking about corner cases - the normal use case is everyone checks out 
from the central server, works with stuff and checks back in.  They're 
not about to start sending entire repositories to other servers.  git 
might allow them to stay of the main development tree for a time - if 
that's allowed by company policy - but it doesn't really change how they 
work.

People use a lot less of version control systems than sometimes forums 
like this would have you believe.  They're a tool.  They don't spend all 
day debating the best way to work.. heck, a significant proportion never 
even merge in the way you or I would.. the fire up WinMerge, view the 
differences and merge manually, then commit the changes without any 
merge information.  That's the way they like it and they're happy like 
that. Us going on about cool new features doesn't affect them in the 
slightest (I believe Arthur has worked on ways to track that kind of 
merge, but don't know how far he got).

If you get 90% of the functionality right then you cover 99% of the 
users.  The others are the noisy ones that complain on forums :)

> That is just as true for cvs and svn; a full copy (except for some
> metadata) is just one 'git cvsimport' or 'git svn clone' away.

.. and that would be logged in the central server, and be noticed, along 
with IP and time/date.

Pulling down an entire cvs repository is a long process (even more so 
for svn).  We do it for migrate and it can take many hours.

For git the whole process is streamlined - even expected, so you 
wouldn't think anything of someone doing it... so it would be much 
harder to nail down one particular user as being the problem.

> Still, I'm amazed at the speed with which git came into existence and
> is running circles around svn (except in the gui department).

I presume git is based on arch, so had an existing system to base itself 
around.  svn always had its problems (I'm no fan of svn.. even less so 
after I implemented the protocol) but is still extremely popular, and 
will remain so for some years I expect.

No system will gain the ubiquity that cvs had a few years ago, simply 
because there's so much choice now.  A few years ago you had SCCS, RCS, 
CVS and a whole bunch of expensive commercial ones, most of which didn't 
even support concurrent development.  It wasn't surprising that CVS 
became so popular.

> git versions trees, not files. Hence you can't have file-wise merge arrows,
> and you can't represent them. This is a purposeful difference which affects
> the way you organize projects, as you can't just keep using the cvsnt way.

You'd have to derive them from the changes to the tree, but they're 
there since a tree is made up of files.  ie. just as you can say 'this 
tree is a merge of these two trees' it's equivalent to saying 'the files 
in this tree are merges of the files in these two trees'.

> It's broken, actually: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

Wonder how they screwed that up?  I'd have never guessed from the 
protocol - although requiring the entire merge history to be sent to the 
client rather than just a mergepoint was probably a clue.

(aside:  I note the technical language... a pet hate.  When I put 
mergepoints in cvsnt in 2002 I never used any word more techincal than 
the word 'merge'.  Even the word mergepoint was originally just a 
corruption of branchpoint..  I think the most technical I ever got was 
talking about points of equivalence - and that lost half the audience so 
I stopped).

>> evs records the merges for all such commits.  If the 
>> client can't provide them, then.. it couldn't whether the server is evs 
>> or anything else, so nothing is lost, it's just a consequence of the 
>> choice of client.
> 
> Which means that no client will behave the same way as with its
> native server? Or will there be one that actually maps all the
> features of EVS in one?

No that's not what I'm saying at all.. a client will behave as if it was 
connected to its native server.  Where there are differences they'll be 
administrative (wrappers files, etc.).

OTOH if a client doesn't provide a means to store certain metadata, such 
as a merge, and evs can't guess it from other sources, then that data 
won't be stored.  Ultimately that's down to the choice of client.  The 
server is perfectly capable.

Exactly how similar we are... I think you can get pretty close in cvsnt 
and svn at least.  Enough so someone that wasn't told it was an evs 
server wouldn't know unless they went looking.  We're already there with 
the cvsnt stuff.. but that's largely because that our heritage and we 
understand it better.

One of the things I sometimes say though is we implement the protocol 
not the server.  Some of the finer details won't be the same.. but the 
aim is that the average user doesn't need to care about it.  If they can 
fire up Eclipse or Tortoise of Visual Studio, and get on with their work 
rather than worrying about what's going on in the backend, then the few 
differences don't matter.

> No, but if I have a svn repository that makes heavy use of svn:external,
> and EVS doesn't support it, I'm rather unlikely to switch.

That one we haven't done yet.. I don't see much (or any, really) use of 
it in the wild.  However if a customer really needed it we would 
implement it.

The same goes for git support.. nobody's actually asked for it yet.  It 
hasn't been beyond the discussion stage.. maybe never will, or maybe a 
customer will turn up with a 10,000 user order tomorrow and make it a 
requirement.  I can dream :p

> But you can't commit to each one of them when they are disconnected
> from each other?

Yes you can - it's designed for intermittent/poor connections.  If they 
were connected all the time anyway you wouldn't need two servers.

> Ehm, nope. He could have given me the patch but then the svn/evs
> commit would carry my name, not his.

Obviously the patch bears the name of the person who does the commit. 
If he doesn't have commit rights then it could never have his name, 
except perhaps in the comments.

They normal way to handle that kind of thing is to give certain people 
their own branch and promote changes from that branch to the development 
branch as permission is granted by the admin.  That way everything is 
recorded - the original change, and who by, with comments, the merge to 
dev by the admin, with comments, and the dates that these happened.

Tony