I'm using project.vim with VIm to manage large code bases with deep directory structures.
When I switch to another one or create (\C) a new one and do a refresh (\R) project.vim starts displaying messages through the whole process for different directories:
<dir_name> is not a valid directory. [O]K:
I have to press Enter all the time, although the directories exist. I took a look at the code and it checks if the path is a directory. They are.
Maybe there is a fix for this. The directories are under Perforce management, so everything is read-only.
I have to stay at the keyboard and keep pressing Enter for it to go to next directories... For large code bases this is takes a long time.
I contacted the author some time ago, but there was no response.
Did anyone encounter this before?
Could it be the it is bothered by the read-only-ness?
Is there a fix for this?
Thanks
The plugin uses glob() for some of those directory checks, which is affected by the 'wildignore' setting. Try
:set wildignore=
If that fixes the problem (and you have at least Vim version 7.2.51), you can modify the plugin's code to use glob(..., 1) instead.
Related
I'm looking of a DTSX file that I didn't make, trying to get an overview of how it works. But I've noticed that every time I open up an Execute SQL Task or File System Task it checks out the dtsx from TFS. I haven't changed anything, so why does it always check out the file?
Because the dtsx file is overly burdensome and mixes UI and data/programming elements in the same backing file? winces
Without seeing the specific file, what I had noticed back when I used version control systems that subscribed to the checkout/modify/checkin pattern is that things such as package configuration, expressions, etc may get re-evaluated as you open tasks which I assume the TFS modify daemon in VS detects the file could get dirty and so checks it out to help you.
You'll also notice that if you run the package, sometimes it gets checked out and marked as modified. Which is totally fun as you get to play: what was I doing before I left my desk? Did I actually make a change or was I just looking?
Not helping matters is that the save action from visual studio always triggers two changes: version build (which is a monotonically increasing number) and the corresponding version guid.
Not an answer, but I can commiserate with your experience. The answer likely lies in the engineering minds in Redmond and was never publicly documented.
I love live-server as a tool for auto-updating a project when changes are made, but I can't bare to use it anymore because it just refreshes WAY too frequently (about every 10-15 seconds) on my Mac.
I can't find what's changing or even IF any files are actually changing. I thought it might be detecting .DS_Store but looking at those files, none of them have a modified time late enough to be the culprit. The verbose logs just show that almost all of my folders in the project changed all at once. All I know for sure is that I'm not manually changing anything.
Anyone have any ideas or even suggestions for a "better" reload-on-change CLI option?
The issue appears to have to do with the fact that I'm using a network shared drive with live-server. If I move the project to my local machine, the problem goes away.
You can try https://www.npmjs.com/package/nodemon
It allowes you to add the Argument
--ignore ...
To ignore files or a whole Directory
Im finding myself using TextMate 2 more and more for development these days
One thing that is bugging me is that it does not seem to reload a file when it is changed externally.
This is a big problem since I use terminal to switch git branches a lot, and it often results in accidentally saving an older version over the new branch
Sadly the TM team seem to have disabled the Issue tracker on github, and documentation just seems scattered far and wide over the web in tiny scraps.
Any ideas?
Right now it reloads the file silently whenever the file on Disk is changed. There is currently no option for a prompt.
Regarding the closed issue tracker: As an alternative, you can always send a mail to the Textmate users list if you find a problem.
I just updated to TM 2. In the past, I have enjoyed using TM to view development.log as I am introducing new or modified code. TM 1 would ask me if I want to revert to what's on disk and of course I would respond with Yes. Then I could see any additions to the log file. Occasionally I would empty the log file with Cmd+A, Delete, Cmd+S. Macromates, please make TM 2 work like TM 1 reloading content.
I also could not find a solution to this problem which is still there, however it is possible to file an issue using this contact page: http://macromates.com/support
Additionally there are hidden setting which cannot be set from the GUI. Unfortunately they don't include and setting for automatic load from disk: https://github.com/textmate/textmate/wiki/Hidden-Settings
I have a really strange problem with my Visual Studio.
I usually press CTRL + S pretty often (call me paranoid, well however I got that habit some years ago now and I really don't want to get rid of it :-))
Now I had the issue that I was editing one file, changing a few dozen of strings according to a spec I had open in Word; so I switch around these two tasks pretty often, make one or two changes and then save.
The odd thing is, every once in a while, after saving, my file is suddenly in read-only-mode, so I cannot navigate through my changes (CTRL+Z/CTRL+Y) and have to reopen that file to continue to code and pray.
Indeed it feels random to me when this occurs:
sometimes I only change 1 thing and save and then it's immediately read-only,
well in other cases it will let me edit several things until it is stuck.
Someone else also experiencing this and maybe got a tip?
Maybe I hit some magic hotkey or something?
My bad, please check if your projects folder is not a synchronized one, so when you edit (change) your project, the backup tool starts to update in remote location for synchronization purposes, so locks the file.
The answer to this problem is most likely that you are currently in Debug mode - i.e. the application is being run. Click "Stop" and it'll allow you to edit the files again.
By default, you cannot edit source files while the Debugger is running.
I have been using XCode with subversion for some time now, no problem was caused when I was using it as a single developer (I was using 2 commands only, commit and add).
But now I have to share the code with another developer (who has never used any kind of version control) and integrating/merging the code has become a nightmare. No problem occur when we are integrating/merging .h/.m files but as soon as it comes to ".nib", "xcodeproj" and ".xcdatamodeld" files, we really don't know what to do.
Whenever we try to merge "xcodeproj", project was getting corrupt and merging ".xcdatamodeld" was kind of impossible for us.
So I was wondering if someone can share his/her experience on how to effectively use subversion/git/mercurial with XCode 4.0 in multiuser environment? or share a link, which can explain how to use subversion effectively in multiuser environment.
Thanks.
Are you doing this using Subversion? For 90% to 99% of the files in your repository, the standard Subversion workflow of checkout, edit, commit works well. However, for some types of files such as JPEGS and GIFS simply don't merge well. In this case, you'll have to do it the way we use to in the old SCCS and RCS days: Before you can edit and commit a file, you must lock it.
Locking a file prevents others from editing the same file and committing changes while you're doing your work on the file. It's crude, but it works. In Subversion, you can always lock any file you're editing, but if the file has the property svn:needs-lock on it, it will be checked out as read-only. You have to lock the file before editing it to make it writable, and you're not allowed to commit the file unless it is locked.
So, for those files, set the svn:needs-lock property on it.
You can automatically set this property on all newly added files (depending upon suffix) via setting the auto-properties in your Subversion client configuration.
And, if you really, really want to make sure that all .nibs and xcodeproj and all of the other flies of these types have svn:needs-lock set on them, you can use my pre-commit hook which will prevent these files from being committed unless this property is set.
There is no failsafe way to merge these kinds of files that I am aware of. So you will have to
try to ensure that only one person is changing these files at a time. That won't work always, so just log what you changed in the file with the commit message. Then if there is a conflict, you can manually resolve it by taking the version that changed more of the file and redo manually what the other person did.
That's normally not a big deal, like adding a new source file to an .xcodeproject, or changing the alignment of an element in a .nib. It's becoming a problem if your project is huge or your nib is containing the whole interface. For it to work well (which in practice it does), you need to split up your projects into sub-projects if they grow too huge.
I had the same problem with 2 other developers Xcode with git. Unfortunately, Xcode project files are an XML file, tracks file included in the project as well as setting. I'm not certain, but I think .nib files are also XML files as well. Someone can correct me on that.
Git did a great job at merging the Xcode project file, and never really had any problems with our *.nib files either. The only time we did have a problem is when we both added/removed files with the same names, or someone did a lot of heavy removing and adding of a lot of files.
The only way we solved this was to have each other push ann pull as soon as we added/removed files. So that way the person had the latest files, and didn't add them in their own repository then pull the latest commit which had the same file in it. Or they work adding changes to a file that was removed or renamed.
That is the best solution we found, as soon as we added or removed a file have everyone else in the team pull. Not a great solution btw. However, you should be committing often anyways.