I have a linux eclipse project checked into our company svn. Works great.
The project is intended to be cross compiled on Windows.
Untill now, I have simply moved the source files between OSes. However, I thought I'd like to let svn do this for me. Should be simple enough, just checkout the eclipse linux src into the VS project dir, right? Wrong!
The correct source was checked out of svn and it worked fine. But when I tried to check it back in i kept getting "Commit not completed filename remains in conflict" errors. I hadn't even changed anything!
Did a little checking. Turns out the linux src directory is pretty much just the source and headers. On the MSVS side the project directory contains the source and headers but also contains a bunch of files that are used by VS with names like projname.vcproj etc. etc.
So, I did a checkout into a scratch dirextory, .\fred. Checked .\fred back in. No problems. Added a new file to .fred, xxx.xxx. Check in reported:
svn: E200009: Commit failed (details follow):
svn: E200009: 'C:\Projects\fred\xxx.xxx' is not under version control
Makes me wonder about those uncommitted Visual Studio files.
So, are those files my problem? Are they breaking the commit operation?
As an alternate solution I am thinking of adding the VS files to the src dir in svn. If linux/eclipse checks them out I can tell eclipse to ignore them (I think it'll just ignore them for me). Any thoughts or recommendations for this approach?
(BTW, i still had fresh source on the linux side so any thing that got clobbered could be safely restored.)
So here is one solution I have working for the moment. I am not sure how totally stable it is.
Caveat: The project i am using already existed as a MSVS project.
In the MSVS solution dir, rename the source dir (MSVS likes the source dir name to match the solution dir name, so this means the source dir may not be named src) to something uninvolved in the solution, like temp.
SVN checkout the src (eclipse like to call source dirs src).
cd into the source dir. Issue the command:
svn changelist msvs *.cpp *.h
Add *.c if needed. "msvs" is the changelist name. It can be whatever you want ti to be.
This will created a changelist for the checked out directory.
Now, copy the remaining files from the temp directory into your source dir.
When you need to do a checkin, cd into the source dir and issue this command:
svn ci --changelist msvs
Note. You have to be in the src dir for this to work.
Related
I'm porting a large project to linux. I wrote all the CMakeLists.txt files, and everything compiles in my machine.
For whatever reason we still use TFS. The old version, not git with TFS.
I'm working in my own branch, but that branch has no build definition for linux. Before I check in, I want to be sure that everything compiles on the server too. So I need to merge my branch to another one, and submit that shelve set to the build job.
In my machine everything compiles fine. But when I run the build in the server, applying a shelveset to the branch that has a linux build definition, I get an error from the build, saying
CMake Error at
/myproject/subproject/CMakeLists.txt:165 (add_library):
Cannot find source file:
/myproject/subproject/IInternalTransactionManager.h
Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
Indeed, that file is not there. Cmake complains about the file not being in the sources directory, which is true, because it is in another directory. But the fact is that I'm not asking for it either! My CMakeFiles.txt file does not include that file. That file is a header which is used in a few files, contains only classes definitions (no implementations), and the directory in which myHeader.h resides has been defined in include_directories. My CMakeLists.txt looks something like this:
set(PROJECT_NAME project)
project(${PROJECT_NAME})
include_directories(
../_include
)
set(source_files
main.cpp
file_that_includes_myHeader.cpp
)
add_library( ${PROJECT_NAME} STATIC ${source_files} )
and my file structure is something like:
/myproject/subproject/main.cpp
/myproject/subproject/file_that_includes_myHeader.cpp
/myproject/subproject/CMakeLists.txt
/myproject/_include/myHeader.h
So, why should cmake complaining about a missing file, if such file is not included in the CMakeLists.txt file? And why would this happen only the build in TFS? My guess is that there is something wrong when applying the shelvetset and is not related to my code, but I cannot prove it.
I compared the code after the shelveset is applyied, and still in that version the CMakeLists.txt does not mention myHeader.h
Or, there is some rule about including headers in CMakeLists.txt files which I'm not aware of.
So, after expending too much debuging I contacted the team in charge of the build process. And as it turns out, the building process in the TFS building definition was definetly NOT what I expected. And of course this was not documented.
Our development is mostly in windows (by far). The linux build has a step before building: a script is launched which parses each Visual Studio project file, gets the included files, and substitutes the source files in the CMakeLists.txt files with the one parsed from VS. Right or wrong, is just the way it is.
I could build the linux build in my local machine because everything was done correctly. The windows build worked too, even though the VS project files sometimes included some files which were not in the source directory but in some header only directory, and somehow that compiled. I guess because the directory was defined in the include directory. But When the CMakeLists.txt files were updated, cmake complained (rightly so) about not finding the files.
So, if anybody experiences similar issues, contact your devops team or whoever is in charge of such things.
I am using Tortoise SVN and Visual SVN Server.
Here is how I am using SVN:
Export Code from Windows7 System and then Copy all code Files to my Fedora System
Make required changes.
Then I Checkout on Windows7 System.
Then Copy All code files from Fedora System to windows7 system.
Then paste in Folder where I checked out.
At this point when I check for modified files. SVN shows me all files as modified, even though they are not modified by me.
Also when I diff unmodified files by me no change is shown, but svn shows that file with red icon.
Could someone please explain the solution this issue?
Note: On Fedora System I am using QT Creator to edit code files. This issue observed with .txt, .cpp, .c files only not with qt ui files.
You can find here how TortoiseSVN finds out if a file is modified.
You should look at the file metadata (date of creation/modification, ownership, etc.)
Edit: If you have issues with end-of-line markers, you can modify SVN behaviour with the svn:eol-style property. See this page for Tortoise configuration.
is it possible to set a 'rule' that tells TortoiseSVN to automatically resolve conflicts on a specific folder?
ie. we have a shared resources folder - "/shared" that we use to store our latest bin files in. when we do a local build, the local bin files in that folder gets overwritten.
next time we do an svn update on that folder the update should pull the latest bin files from SVN and overwrite the previously locally-built bin files but this will throw a conflict because the files are binary and cannot be merged (and, should not be merged anyway)
we would like to setup a rule that tells tortoise to always "resolve using theirs" on that /shared folder ("svn update -R --accept theirs-full")
There's a SVN misuse here. If the files should not be merged as you said, the directory should be set to ignore all .bin files (svn:ignore). It doesn't make sense keep in version control binary files that are changed frequently causing so much collisions.
In your place, I would delete all .bin files from this folder. If it's really necessary to keep the files versioned, I would create a directory and place these .bin files in there, avoiding frequent changing.
But if you really want to keep the files as they are, I recommend you to write client-side hooks for post-update events. See TortoiseSVN Docs for more information.
I just installed VCSCommand and I'm getting an error of "No suitable plugin" whenever I try to run a command. I have a filed loaded in Vim that is in a directory with a mercurial repository.
I found some explanations that the "No suitable plugin" error may be displayed if you're not in a "working directory", which I took to mean that the file you're editing should be in a "working directory" of files checked out from the repository. The problem may that (as a new user to Hg) I don't grok Mercurial properly. The file I'm editing is in a directory where I created an Hg repository just to track my local changes. Commands I issued were 'hg init', then 'hg add' and I've been using 'hg commit', 'hg log', and 'hg diff' happily since. Is this directory not a "working directory" of the repo? Assuming this is the problem, how do I "checkout' the files from the hg repo into a working directory?
Or maybe the above isn't the problem with the "No suitable plugin" error at all. I do have the vcshg.vim file in the correct plugin directory, so the plugin is there.
Thanks, any help appreciated.
UPDATE: Just in case my use of mercurial was the problem I tried creating a 'clone' of my main mercurial repo and editing files in the clone. Still get same 'No suitable plugin.' message.
ALSO: I left out of original message that I'm running on Windows, and I think I've tracked things down to improper quoting of escape codes in strings. Will provide further update once I get full resolution.
I did get VCSCommand going fine. I think the issue had nothing to do with Mercurial, rather it had to do with problems in VCSCommand with quoting of system commands on Windows. At least that was the major problem.
To get VCSCommand working I first made sure that the variable b:VCSCommandVCSType was set to 'HG'. It was not getting set for some reason and that was why I was getting the 'No suitable plugin" error.
Second, I had to modify a line in vcshg.vim. The s:Executable() function consists of a one line 'return . . . ' function. The shellescape() wrapper around the system call was quoting improperly; after I removed that it works just fine. (Same problem may exist in the vcsXX.vim files for systems other than Mercurial, I haven't checked that.)
I think this quoting problem exists only on Windows, and may have cropped up because the main developer doesn't have a Windows machine to test on. . . .
First to answer the "working directory" question: your repository is your working directory. Unlike cvs/svn, you do not need to checkout files to edit. You just edit.
(FYI hg aliases its update command to checkout and co to help svn users, but hg update is a very different animal.)
Without knowing your complete environment (platform, vim installation, etc.), I can only guess that the "No suitable plugin" error is due to your VCSCommand files not in the right place. I tried its latest version 1.99.42 with my ancient vim 7.2 on cygwin by cp VCSCommand/plugin/* ~/.vim/plugin/, vim a file in an hg repo, then :VCSStatus shows me the correct result.
If you have other VCSs that VCSCommand supports (cvs, svn, svk, git, bzr), try it in one of their repositories and see if you get the same error. If you do, then it's definitely a VCSCommand installation problem.
So I have scons working with an alternate build location (build/ for my output files, src/ for my input files) and it works great. Except for one thing.
I'm using an IDE (TI Code Composer 4) to debug my program. I point the IDE at the output executable to run it, and what it uses for the source files for debugging is the build/ directory. I don't really care, except when I go to edit the file in the IDE, for example main.cpp, the file is really build/main.cpp which gets clobbered as soon as I run scons again. I have to remember to edit src/main.cpp instead. I am aware of this issue and yet I make the same mistake often.
Is there a way to have scons make the source files it copies into the build path read-only? (I'd ask how to get TI CCS4 to use the right source files when it is debugging an executable, but I doubt I'd get any answers.)
This page has information about wrapping InstallTargets with a chmod call.
FYI, the scons user list is quite active with many knowledgeable people and you can get answers pretty quickly.
You could always tell scons not to duplicate source files in the build directory:
SConscript('src/SConscript', variant_dir='build', duplicate=0)