Helps us out, rate NautilusSvn’s performance
Note that when you encounter a working copy for the first time during a session Nautilus will hang while NautilusSvn does an initial recursive status check, for extremely large working copies (think thousands of items) this can possibly take up to a few minutes. Consecutive status checks after the initial one should be much faster and in most cases a status check will not even be executed anymore (cache hits, < 1ms).
[poll id=”2″]
Thanks! Be sure to leave any comments you have in the commentary section below.
It is faster than it was previously but it still eats a lot of memory.
I have quite a bit of code checked out at work. In fact, let’s see… the top level directory is a total of… 1.4GB.
Now, bear in mind that is also compiled classes and things like that that aren’t under SVN, but it IS a lot fo code.
Nautilus is sitting at 248MiB of RAM usage at the moment and this was a clean restart to take the new plugin.
It also takes a minute or two the first time you open that top level directory (freezing naut while it does this), presumably because it’s running through the entire tree finding file statuses to cache.
As another test of sorts, I opened the old code branch I still have, it froze naut for ~2 min or so and now the mem usage of naut is up to 338MiB. That directory is about the same, 1.4GB.
Once it’s done its caching it is pretty fast though.
I really like nautilus i started using since the first release but even the lastest i always find myself uninstalling it because unfortunately it’s slow . i have many svn checkout in my document root . and when opening the folder it always take some time ( i don’t mean the initial check status). but i found the new menu quite cool and polished. the only thing i’m not using it right is the response time when opening folders.
When I have a Nautilus window open with a LaTeX file in it, it takes much longer to compile the LaTeX file if the directory is under version control. This hasn’t been without NautilusSVN.
Still, thanks for the extension. It really nice.
It never sprang to life after it asked for the login and password. However, I didn’t have time to wait long 10-15 minutes. Had to checkout about 1500 files for 1.5 Gig over LAN. Had to use console for a checkout instead, but after the initial checkout nautilussvn seemed to work ok.
Still great idea! I was searching for something like tortoisesvn for my ubuntu. Hope to see the development!!! I really mean it!
On my (Ubuntu Hardy) system NautilusSVN is pretty slow, probably because I have a lot of working copies on my system. It’s really annoying that nautilus just hangs completely until NautilusSVN has finished updating the status of all svn files. Why doesn’t NautilusSVN check this in the background? While doing the background check it could just display some sort of ‘in progress’ emblem for the files/directories it didn’t checked yet. That would be a great improvement.
Besides the lack of speed NautilusSVN is great btw!
Great initiative but unacceptably slow even after the initial scan. This is a quad core cpu, Ubuntu Hardy 64bit, with a WD Raptor 10.000 rpm hard disk. I’m sorry to say there’s no way I can use it productively. Double clicking a folder sometimes doesn’t work and I have to single click on it, then double click for it to open. It takes 100% of one cpu core for too long.
Keep hacking on it, the functionality looks great, but do improve the responsiveness. It shows promise but we can’t use it as it is right now.
I think this latest release is a vast improvement over the previous. It’s becoming more of a solid application / clone of tortoise svn. One thing I don’t like is it tends to lock up nautilus, usually when figuring out the status of folders. I’m not 100% clear on why this happens yet so I haven’t filled a bug report but it’s a serious downer.
I work out of a single “Projects” folder for all projects at work (currently about 3Gb worth of assets under source control), and loading this folder takes about 60 seconds. During this time Nautilus is completely unusable (and I think my desktop icons disappear too). However, once it loads, the performance is good. The only other issue I’ve had with 0.12 is the context menu not recognising if there are files/folders to commit (which is usually fixed by a refresh).
Having said that, NautilusSvn is by far the best Subversion client I’ve found for Linux (even in it’s beta state). Good job guys. Can’t wait for a final release and the repo browser functionality: then hopefully I can delete my Windows VM and uninstall RapidSVN. :)
I really loved this – not much of a command line guy for SVN. Unfortunately I work with a (very) slow SVN repo, and the fact that the nautilus UI locks up while it checks the repo made my machine totally unusable (0.12) and I had to reinstall.
Keep pounding on it – I would love to try it again once this is improved.
SG
I experience the same behavior as “Anonymous Bystander”. On larger repositories (in files number, not in bytes), the first double clic on a folder has often no effect, I have to do it again. Also with these folders, right clicking on it and simply hover the NautilusSVN entries hangs Nautilus a few seconds.
By the way I would say this nautilus subversion plugin is on par with SubdiverSVN now (http://subdiversvn.sourceforge.net). It was better before, but NautilusSVN is is heavy development now whereas T.Yamada seems to be alone. Also the Ubuntu deb is simpler ans works on my Ubuntu Jaunty 64 bits, whereas SubdiverSVN need to be build.
Hi, thanks for taking time to create this program, even when it’s not the fastest on earth. It is good to have
such a tool for Nautilus too. THANKS!
Excellent work guys, I was really looking forward to this tool. Performance – and, mostly, usability – has improved a lot since previous stable version, nonetheless I feel there’s lots of space for improvement. TSVN seems generally faster for same working copies on the same hardware. Python overhead? BTW do you link directly to libsvn or do you spawn a separate svn process in order to do the processing?
I love it. Only thing is that is can be quite slow, especially after doing an update or commit and traversing higher up in the hierachy. I’ve had Nautilus lock on me for 10-20 min at a time. Hope this will be improved in later versions :)
A great tool but I had to give it a 6.
Uses far too much memory and is still very slow on large projects.
I’ve had to remove it from one computer because just exploring an SVN folder to find a single file I wanted to edit would slow the computer massively. I’d need to kill nautilus afterwards to get my memory back.
I’ve been waiting a long time for something like this, and I look forward to using it again once the memory and speed is sorted.
Was slow on Ubuntu 8.10 and even sometimes stopped responding for no reason. But now that I have the latest Ubuntu 9.04, NautilusSVN beta works fast with no problems.
Only just found your app so I’ve not really used it yet, but all I can say is thanks! This is a great project and well worth persuing.
[…] on the results so far from the performance poll with a sample of 130 users it seems 38% of NautilusSvn users are not satisfied with the current […]
I can’t say that I find this tool usable yet. I’ve tried it before and the performance was so bad that I removed it immediately. This time, I’m playing with it a little more.
Yes, my project is huge (20,000 files), but that should not matter. First there is performance. This is supposed to improve once the initial scan has been done. For me at least, there was not enough improvement. I am constantly wondering if my double-click took effect, because nothing is happening.
Besides that, I cannot even traverse into a particular directory. It simply refuses to go there on my double-click. Don’t know why.
Further clarification to my previous comment:
I retract part of my comment about performance after the initial scan. It is significantly better going down. For some reason, however, using the “Up” button is still pretty slow (enough that Nautilus grays out temporarily).
The inability to traverse into one particular directory is part of the reason I thought the performance remained slow. I cannot traverse into this directory AT ALL.
I’ve got a TortoiseSVN checkout here which consists out of 22241 files and it will load in under 30 seconds. Entering that very same directory again (even after the internal cache is gone) will take just 6.179s, this is because of what Alex said in the File access times and caching.
Traversing through the directory (both ways, up and down) is not a problem for me at all, with the internal cache filled it means everything loads with only a tiny delay compared to usage without the extension.
Here’s how you can collect the numbers (you should try this too and reply to me with the numbers):
You can also try the same for the svn status command:
So yes there’s room for improvement but that 5s one on nautilus –no-desktop was without having an internal cache and without having Nautilus running. With the internal cache it is also near instantaneous. Here’s a little one with using internal timers:
When traversing I get times between 1ms and 50ms per item (file/directory) for the actual status checking. However, building the context menu on get_background_items and get_file_items (when clicking) seems to consistently take quite longer, depending on the item in question (for example 500/600ms for the root, 200/300ms for some sub directories etc.). I’ll be looking into this.
There’s also one issue that maybe aggravates initial loading times and that is that when you enter a directory, the status check is not done for that directory but a separate check is done for every sub directory. I’m not actually sure if this is always the case because some methods are conflicting here and there.
It’s quite simple though, I can only develop for what I can see and if you guys are experiencing behavior that I cannot reproduce I cannot make any guarantees that anything I do will solve your issues. I know there are a couple of bottlenecks but the behavior a lot of folks here are describing is completely foreign to me.
Also, just being by myself working on what is quite a tough issue isn’t exactly what I’d call fun, having nobody to spar with just makes things a lot harder. Sure, it’s a challenge but I’m getting headaches from time to time just thinking about how to handle large working copies.
Just wanted to point out that the two offenders that take up the most time in building the context menu are has_locked and is_locked. I’ll be looking into precisely why.
UPDATE: ok turns out these methods call info2 which just like status will recursively walk the entire working copy. Even is_locked doesn’t pass recurse=False.
When browsing folders with svn sub-folders, nautilussvn locks up nautilus for about 10secs.
I like your work, and use it every day, but i have to give you 5 – Disappointing
This tool is a good proof of concept, please keep up the good work! I would love to see this tool mature to a fully functional, usable TSVN-on-linux.
As-is, it is far too slow (dual Quad-core Xeon w/8GB RAM, takes 5-10s to change dirs) and the diff viewer doesn’t work. But I think in 6 months it will be a great tool to check back on.
Thanks and keep on coding!
Sam
Performance is acceptable, especially since NautilusSvn uses caching now. However, it is still disappointing when my “repo” directory hangs for half a minute or more every morning before I can begin my work.
* Perhaps NautilusSvn could duplicate TortoiseSvn’s behavior in the caching department. It somehow manages to get this right–I cannot even notice it is working. Is it just remembering the cache from session to session?
* Is there any way NautilusSvn could do it’s cache recursion without locking up Nautilus? This is the only performance issue I see, but it would be much less noticeable if I could actually start using my working copy while it finishes its task behind the scenes.
I love it.
I have used cvs and svn, and fell in love with tortoisesvn. Finally having something as visually convenient as tortoisesvn on ubuntu is a dream come true. All the scripts one can add to nautilus manually do simply not match the visual icon convenience to get the status at a glance. Having installed nautilussvn I even noticed that I had a complete directory hierarchy of about a hundred files sitting around for what must have been a year or more after a manual svn add for the final commit.
The convenience of nautilussvn is brilliant. I appreciate that this depends heavily on the size of your projects, and the hardware of your computer, but, still, it is so good to finally have this under Linux, too.
Incidentally, my largest repository is only a couple of thousand files, but in that directory hierarchy’s top level, nautilus refreshes within a couple of seconds at worst. Is the performance heavily linked to the server’s response time? Mine is on the same computer (AMD Phenom II X3 720) via https (apache) whence there may be no network delay. Could this make a difference? I access the same server from some windows machines over the network with no better performance under tortoisesvn.
Keep the good work going!
exactly what I want, but very slow. More than slow. Hangs my nautilus after any operation for up to a minute.
Shame.
i have a repository with approx. 5000 files in about 100 directories. on the same machine, winxp and tortoisesvn are working wihtin an acceptable performance range. whereas ubuntu 9.10 and nautilussvn are blocking my computer for minutes – and i am not talking about initial scans …
i realy hope that you are able to solve this performance issue! i would realy like to use nautilussvn as it is as convinient as tortoisesvn …
best reagards and thanks for the good work you have already done,
tobias
Only just installed it, so I won’t vote yet. It looks great though! Obviously it is very much like TortoiseSVN – but that is a great thing, keep doing that. It really helps for people like me who develop on multiple platforms.
The first things I notice is that it doesn’t work on SMB shares through Nautilus. Now you have caching added, can we add support for GVFS places.
Suggest adding a ‘Repo Browser…’ option that (for now) fires up RapidSVN (or other peoples’ favourite) with the current repository path. (Later you can add your own if you get to that. But another and better approach would be a separate project to add GVFS support for SVN repositories to Nautilus. Then we can check-out by dragging and dropping a folder from SVN to a file system.)
I have just installed http://nautilussvn.googlecode.com/files/nautilussvn_0.12-1ubuntu2_all.deb and it freeze my computer every time I browse sshfs svn projects folders. Looks like nothing changed from my last try to use nautilussvn in january. Sorry to disappoint you. Sad, but true.
Ubuntu 9.04
I have used nautilusvn lastest beta version, it’s definitely the nicest SVN client out there in Linux. But one thing I dont like about it is the slow performance on large files and directory, It takes too long.
I really hope you guy can solve these performance issues or a SVN for Thaunar may be? :P
Thank you for your good application, all the best to you and your applications :D
Well done! I compared TortoiseSVN + Explorer under Windows XP with NautilusSVN under Ubuntu 9.04 on the same box.
NautilusSVN is already more than excellent proof of concept. The functionality is already useful. Speed could be improved and I hope it will.
I have a single ~/src folder where I keep subfolders for the different projects/repositories. Entering ~/src for the first time was painfully slow. Only after reading the explanations on this blog I developed an understanding and considered it acceptable. I’d suggest displaying a notification on the screen during the initial recursive status check, and giving the user the option to stop it / resume it later / run it in the background.
Keep it coming!
Hi guys!
NautilusSVN has a serious performance issue and it could be fixed with one simple change (!). This change (*) is also implemented in TortoiseSVN, making it seem much more responsive.
Consider this setup:
/home/joe/work/project1/an_svn_directory
Now suppose I just want to edit a file OUTSIDE of the svn directory (that is in my project1 folder). At this point I really don’t care if the emblem on the svn folder is correct or not, I just want to edit some other files. But NautilusSVN goes and recursivly checks the whole tree, rendering my Nautilus unresponsive.
User workaround: enter the adress in the adress bar (unhandy) or create a nested forlder for the checkout directory (ugly and unlogical)
Therefore I propose this fix/change:
* Only recursivly check all the subdirectories once the main checkout folder is actually opened. Usually there are only a handful folders and files in the checkout root, so it’s really not a problem to quickly look at them all and see if they are up-to-date. TortoiseSVN displays an emblem on the root folder too, BUT DOESN’T UPDATE IT EVERYTIME you browse around the folder in Explorer. So maybe the root emblem is a little out-of-date, but it doesn’t really matter if one isn’t using the svn contents anyway,,,
I’m looking forward to future versions of your works!
Thanks for the extension! it’s just what i was looking for!
I installed using the .deb and it is not useable at all. Nautilus freezes on the order of minutes before opening any folder. Ubuntu 8.10
Other than that, seems to be really convenient and Tortoise-like.
Nice work!
But takes too long when opening a svn folder (NOT only the first time !!) – whether it is a root or somewhere inside the hierarchy.
For anyone watching this topic, we’ve made some recent changes that the brave amongst you might like to try out. No release just yet, but if you’re willing to run a development installation of NautilusSVN, we’d welcome your input…
I have just installed the trunk version (Revision 1483) and it’s a lot better!
It’s hard to say if it’s faster, but it is very nice that it is performing the update in the background so nautilus does not freeze.
Keep up the good work!!
I just installed this awesome piece of software, but i must say, that the repository status updates are very disappointing.
Even on my very small checkouts (around 100 files) it is extremely slow – also on subsequent updates.
I’m running the latest 0.12 beta.
But keep up the good work! It’s nice to finally have found a nautilus plugin which looks like TortioseSVN :)
@Edit
Maybe is should say, that i am using ArchLinux with GNOME 2.26.3
Well, I just found out about NautilusSVN and installed it on Ubuntu (9.04).
It’s amazing.I didn’t notice any delay for repository update (it was a split of a second). Maybe my repos are kind of small (less than 100 files each, about 15 different working copies).
I’ve always envied my friends working with TortoiseSVN on windows. Not any more!
Just a quick question: is there any way to have an emblem for out-of-date working copies? I mean, there’s no UI for svn status really. I understand, if something is locally modified, the emblem shows it; but what about some files being out of date? status command is not available, and emblem doesn’t show that either.
Thanks again and keep up the good work!
This functionality has been discussed but not yet implemented, see http://code.google.com/p/nautilussvn/issues/detail?id=21.
I’m seeing issues when I operate NautilusSVN and TortoiseSVN on the same folder. Try this: dual-boot a machine Linux and Windows (or virtualize one). Share a folder between them. Use NautilusSVN to check out from a repo. Switch to Windows and use TortoiseSVN and make a commit. Switch back to Linux. NautilusSVN no longer recognizes there is a branch checked out in that folder.
The above scenario describes my development environment. I’m doing multiplatform C++ work, and maintain a single folder which is located on a partition accessible to both Ubuntu and XP on a dual-boot machine. Any workarounds would be welcome!
I’ve been using it for quite a while now, say about a month. Previous OS was Windows Vista. I had tortoiseSVN back then. I was glad to find a similar app on ubuntu.
What annoys me is that whenever I try to open a folder that has svn, it takes me 3 left clicks to open it. (highlight folder then double click). I know it’s a little weird but that’s how I manage to open directories with svn.
It’s still a bit sluggish, but overall, I’m ok with it.
Ubuntu 9.04
Excellent program!
Very good! Author, you are great!
Please ask me, why it isn’t in official repo?
—
Katrin from Russia %)
Hi Katrin, thanks for the kind words! The reason this isn’t in the official Ubuntu repository is because we haven’t yet tried to get our package accepted into the repo (I consider it a big step).
RabbitVCS (0.12.1) is hardly usable for me as I have a HUGE repository. It’s 16GB worth of documents, images, xml, you name it. It takes forever (~30-60min) to just come up with the first green or red icon. I thought I can live with that as I hardly ever restart my computer but once it’s loaded it’s still quite slow to give me status icons and chows an enormous amount of memory (nautilus 1459M virt/650M res, python service 1093M virt/186M res).
Please could you improve this performance (willing to beta test anything you come up with) as I’m reverting to the command line but my colleagues are not command line warriors like me so they’re stuck…
Kilian — you could try the current state of RabbitVCS in SVN if you like (you can even build yourself a quick deb from it if you use Debian or Ubuntu). I recently made some significant changes to things to improve responsiveness and performance (which I meant to blog about but haven’t gotten around to yet…)
See:
http://wiki.rabbitvcs.org/wiki/development/installation
http://wiki.rabbitvcs.org/wiki/development/packaging
I stoped every thing I can. Include Status Checher, File Attributes, Emblems, Logging. But Nautilus still hang long time for new working copy, at least 60 second for Android 4.0 patch.