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: > 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