[cvsnt] Betr.: CVSNT to CVS
tony.hoyle at march-hare.com
Wed Apr 8 13:43:22 BST 2009
Andreas Krey wrote:
> Waitaminute. You need to convert the full history that EVS holds into
> a git repo, otherwise the git (client) users will complain because
> a) the history isn't there and b) if you hand out partialized histories
> the commits won't have their usual identities. If the git users aren't
> able to pull from one another, why should they bother at all?
No problem with enabling that... Personally I find the concept of
transmitting whole repositories between users silly, but if customers
wanted it there's no reason why not.
> Also, as a git user I would expect to be able to pull from one EVS
> repo and then push one branch into another EVS repo; and would
Take a scenario. Your company has an evs server. They let you use any
client you like, but there is of course only one centrally, fully backed
up and audited central server.
If they want another evs server then evs servers can sync between
themselves just fine. There's no purpose in trying to use git to do
that - in fact it'd be missing important metadata, so would be a very
It also highlights the fundamental problem with git - someone can take
your entire repository history and copy it out of the company, and you
can't do a damned thing about it. Corporate customers are big on
auditing and security - neither of which git can provide, by design. It
also lacks things like locking, again because of its distributed nature.
Evs can help as at least the central server has these functions, but
it's not entirely a solution.
It's a good solution for opensource development, but then evs is just
not aimed at that.
> Just branch out (in cvsnt) one subdirectory, start working in that
> branch, and merge back a few (not all) files. The history you
> now have in cvsnt cannot be properly represented in git (and possibly
> neither in svn). You can represent the state of the files in all
> commits, but what is missing is the correct merge tracking information.
What you describe there is basic version control. I don't see the
problem. It's simple enough in SVN (although SVN's mergepoint stuff is
pretty bizarre). 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.
>> evs is *already* a generic bridge. It works.
> Between cvsnt and svn?
> How do you map the trunk/tags/branches metaphor? How do you import
> from svn when the used style doesn't match your way?
There's a generic mapping. Is said elsewhere that it should probably
create virtual directories called tags and branches, but doesn't right now.
Import from svn is easy enough. You might have to move some things
around to support the cvsnt clients, but it's not a major hardship.
>> There are rough edges, mostly due to time constraints,
> It is my argument that the time constraints can't be lifted
> if full interoperatility between cvsnt, svn and git clients
> is to be achieved, especially on already-existing repositories
> that did some strange things.
The time constraints are mostly because we have limited budget and one
active developer. The hard work is done, and if we had someone else I'd
probably put them on ironing out the remaining rough edges on SVN first.
I see no reason why that particular module shouldn't be near perfect.
The same with TFS (subject to implementation of the bug tracking
modules for it etc., which is a longer project). That covers the major
> git doesn't store renames either; they conceptually just the store
> the current state of the tree after each commit.
You can determine things using heuristics, or just treat it as a bunch
of adds and removes. The latter approach means you've lost some object
history, which is unfortunate but unavoidable if the client doesn't
> Also, svn:externals aren't anything elsewhere, as are git
> submodules or cvs modules. There are some possible mappings
> between each other, but none of them are the only possible
> way of doing things, and doing the mappings at least requires
> some project-specific configuration.
Those are implementation specific details. They don't actually change
At some point evs may well sprout its own generic module system that
maps across all clients. You can basically do it already with symbolic
links (although no clients currently create them except for cvsnt alias
> Pfft. svn and cvs are almost the same, except for the stupid
> tags-are-in-file-namespace idea. They both give you the advantage
> that you can basically hide the actual history from the clients.
> To interoperate with git you need to *give* them the full history.
Don't see the problem with that, provided your IT manager doesn't have a
problem with it..
> That's the problem: git was designed not to do this.
That's not a problem. evs was.
> Did you design the storage model in a way that makes it possible
> to actually work distributed? That is, do a branch here, and later
> push that branch to the other server where other commits have already
> been done?
That's what the evs sync protocol does - it's how we handle keeping many
servers in sync simultaneously.
> 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.
Or you could just send a patch. It's just another way of working.
> (I had the same problem just yesterday under svn. Someone needed
> a little modification and had it in his sandbox but wasn't allowed
> to commit. Now he needed to find someone to grant him access, or
> to carry around that file to a sandbox whose owner can commit. In git
> he could just commit it locally and tell someone with commit rights
> to the official repository to pull his change and push it to central.
> Without even losing the commit attribution.)
And if the official repository was evs it would work exactly the same
way. Except the user could have still been working under svn and you
could have used git to keep the modified file temporarily.
OTOH a user shouldn't be modifying files they don't have rights to
*anyway*. I'd deal with that problem first.
More information about the cvsnt