Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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 suboptimal solution. 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? Yes. > 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 ones. > 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 support it. > 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 what's stored. 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 tags). > 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. Tony