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.
On Wed, 08 Apr 2009 13:43:22 +0000, Tony Hoyle wrote: ... > No problem with enabling that... Personally I find the concept of > transmitting whole repositories between users silly, 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. ... > 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. 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'). > 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. 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. > 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. 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. > 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. You could avoid commits to a specific file on your official repo, and that is all cvs/svn provide either. Local changes are possible (chmod exists), and committing into the local repository *is* a local change. Also the server auditing doesn't prevent further passing around of stuff that once came into any sandbox. Foolish to restrict svn access and then check it out with umask 022. ... > It's a good solution for opensource development, but then evs is just > not aimed at that. It already occurred to me that your target audience is a bit different. Still, I'm amazed at the speed with which git came into existence and is running circles around svn (except in the gui department). > >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. 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. > It's simple enough in SVN (although SVN's mergepoint stuff is > pretty bizarre). It's broken, actually: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html > 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? ... > >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. 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. ... > >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. But you can't commit to each one of them when they are disconnected from each other? ... > >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. Ehm, nope. He could have given me the patch but then the svn/evs commit would carry my name, not his. > OTOH a user shouldn't be modifying files they don't have rights to > *anyway*. I'd deal with that problem first. The module responsibles are a bit easier to reach than the sysadm that first has to ask someone in command whether the request is actually valid. And possibly we actually *don't* want this guy to have write access but still want to put in those things we checked first. Andreas