[cvsnt] Betr.: CVSNT to CVS
tony.hoyle at march-hare.com
Wed Apr 8 19:13:31 BST 2009
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
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
> 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
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
>> 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
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.
More information about the cvsnt