mdutt Posted November 18, 2011 Report Share Posted November 18, 2011 Hello everyone, first of all: congratulations to the new 4.0 Plastic SCM. It's really nice! We're about to introduce Plastic SCM as our main repository system and I liked it from the start. Now what I noticed while working in GUI mode. Everytime I start a diff between my locally changed files and the last changeset on the repository it takes very much time until Plastic is showing me the two text windows. In the meantime it says: "Calculating differences". We aren't on a productive environment already, because we're still in evaluation mode. So our configuration at the moment is a standalone machine running the repository server with a MS SQL CE database backend. Might that be the reason for the poor performance? A general improvement would be to start the diff tool in a new thread so you can continue using Plastic while differences are calculated. At the moment the whole GUI freezes while taking this action. The text files compared are very huge indeed. We are talking about Visual Fox Pro binaries converted to text files so they're rather long because every method, class variable and some meta data are stored in one single text file... Don't know if you were aware of that when implementing the diff tool call in the program. I'm looking forward to hear from you. Marcel Link to comment Share on other sites More sharing options...
psantosl Posted November 21, 2011 Report Share Posted November 21, 2011 Hi Marcel and thanks for the suggestions! In fact, we must implement an improvement! I'll be talking to the team tomorrow about this. Thanks, pablo Link to comment Share on other sites More sharing options...
mdutt Posted November 22, 2011 Author Report Share Posted November 22, 2011 Thanks for the fast reaction! So it's a known issue in 4.0 Not good. This will massively delay the introduction of the system in our case. Actually the Diff tool is heavily used in my company so it's no option to wait up to a minute or so - per file. Would be very nice if you could tell me a timeframe within you want to fix these issues. Thanks in advance! Marcel Link to comment Share on other sites More sharing options...
psantosl Posted November 22, 2011 Report Share Posted November 22, 2011 Ok, it wasn't a known issue because normally diffing files takes like a msec down here. I guess your problem raises there because your files are actually HUGE, doesn't it? I mean, with regular source code files it is not a problem, is it? I'll try to double check this with the team today. Link to comment Share on other sites More sharing options...
psantosl Posted November 22, 2011 Report Share Posted November 22, 2011 One question: do you mean the list of "pending changes"???? Link to comment Share on other sites More sharing options...
mdutt Posted November 22, 2011 Author Report Share Posted November 22, 2011 The biggest one got 1.79 MB This is also the one that takes the most time whenn diffing files. And you're right - we also got some C# Class-Files which are fast as hell when you diff them. Sadly there's no alternative like splitting them up. A Microsoft tool is doing the conversion from binary (a table structure) to text files... What I'd like to know: what's causing the time lag? Is it the comparison algorithm itself or is it the access to the DB backend? Second possibility maybe resolvable by ourselves. First one means you are the only ones who can improve things in this case. Please also notice another topic a colleague of mine started here He's trying to move the DB from SQL Server CE to a real SQL Server and got some trouble with the Admintool.exe while migrating. Maybe we can give you some feedback about the performance differences between the two backends when this step completes. Thanks a lot for your dedication! Link to comment Share on other sites More sharing options...
mdutt Posted November 22, 2011 Author Report Share Posted November 22, 2011 One question: do you mean the list of "pending changes"???? You mean the diffs at the bottom part of the page? Yes this is one place where this happens. But also if you just diff a current change with the previous changeset manually. Link to comment Share on other sites More sharing options...
psantosl Posted November 22, 2011 Report Share Posted November 22, 2011 We're checking it. One possible workaround -> go to the options, diff, and check the "external diff" instead of the built-in one. Link to comment Share on other sites More sharing options...
mdutt Posted November 22, 2011 Author Report Share Posted November 22, 2011 I just proposed this option to my supervisor. Maybe this will save us weeks up to months of keep on working with Visual Source Safe (which is in fact absolutely outdated for a repository...) Thanks for your effort again. Would be nice if you could let me know when there is some news. Link to comment Share on other sites More sharing options...
psantosl Posted November 22, 2011 Report Share Posted November 22, 2011 The external diff is still built in in Plastic. Alternatively you could hook up an external diff tool (check our blog for more info http://codicesoftware.blogspot.com/2011/05/setting-up-plastic-scm-with-external.html) to deal with the specific huge files we've problems with. Link to comment Share on other sites More sharing options...
mdutt Posted November 23, 2011 Author Report Share Posted November 23, 2011 I tried to use the "external" Plastic Diff Tool. In some cases it's actually faster. This might be a good workaround - at least for some time. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.