I'm using CVS in Eclipse. I have a big set (approx. 600) of revised text files that I'd like to CVS commit. Each file is about 1MB. I found if I try to commit the whole parent directory or any large number of notebooks, say 50 of them, the commit never work. I use highlight multiple files in Package Explorer -> context menu -> Team -> Commit to do that. Right now, I just select a small number, say 10 of revised files and commit and it does work. But it often takes multiple tries for it to work. Is there any configuration or trick I can use?
I'm using Eclipse 4.3 with memory settings
...
-XX:MaxPermSize=256m
-Xms1024m
-Xmx1536m
...
in eclipse.ini.
Storing the files in other places or VCS repository is not an option. Using other CVS client or method for committing is OK.
As far as I can tell, commiting files from eclipse list the files as the arguments of a classic cmd command "cvs commit file1 file2 ...". There is a limit on the number of the arguments in such a command. Therefore it can not handle larger number of files. The size can be a problem too.
I needed to commit about 30 000 files at once and the only way I was able to do this was writing a script and doing it recursively for every folder using "cvs commit -l" (invoked when folder was visited recursively).
I have tried tortoiseCVS but it crashed on the memory (needed around 1.3GB of RAM for this operation a it could not allocate it).
Related
I'm using Eclipse Remote synchronization to upload a PHP project from my Windows workstation to FreeBSD VM, where my web server is running. In order to make the synchronization Eclipse create on both machines .ptp-sync directory where stores the git objects.
Initially the project is ~1MB. But after every save (which triggers sync) this size increases to 2MB, 3MB, 5MB, 10MB etc, on both machines. After a couple of synchronizations it goes through hundreds of MB, to GBs. Once it reaches even 11GB. Of course the synchronization starts to take, instead 1-2 sec as it is initially, 1-2min. In such cases I should delete both .ptp-sync dirs and init Eclipse sync again.
I notice that the largest files are in .ptp-sync\objects\pack\
My last test, after 3 saves (and syncs) the repo increase steps were 77MB - 138MB - 267MB - 396MB. Just before that I try
git -C .ptp-sync --work-tree=. gc --prune
which reduces the size from 140MB to 77MB, but after 396MB it doesn't reduce anything. Next save make the repo 779MB.
One of my guesses was that it is not ignoring .ptp-sync which causes to push it everytime, although there is /.ptp-sync in .gitignore file, and also in Eclipse Preferences->Remote Development->Synchronized Projects->File Filtering.
P.S. Ah, and of course this does not happen on my colleague setup which is prity the same - he also uses Windows and Eclipse with a copy of the same VM.
I figure out how to handle this situation. As I guess the .ptp-sync directory even it was added into .gitignore it wasn't actually ignored, and this cause its recommit on every repack.
The solution is to add into .ptp-sync/info/exclude the row /.ptp-sync/. Maybe the synchronization doesn't use .gitignore by default.
For different ways of ignoring files, the following link can give some info: https://help.github.com/articles/ignoring-files/
I have a freshly checked-out svn working copy in my eclipse workspace, running on Windows 7. In the repository, both in the same directory, I have the following two files (that only differs by the extension letter case):
grey_tube_with_border.PNG
grey_tube_with_border.png
Unsurprisingly, Windows isn't happy about it, and cannot hold the two files simultaneously in the working copy. This cause me a lot of troubles (for instance, when I try to merge the WC with a different branch).
On the other hand, I can't find a way to rename / delete one of the files. I tried commit, override and commit etc. Nothing works.
How do I solve this problem?
Use command-line tools, or the Repository Browser in TortoiseSVN, to do a rename directly on the server without a working copy.
Example:
svn move http://example.com/svn/grey_tube_with_border.PNG http://example.com/svn/grey_tube_with_border.2.png
Then you should be able to svn update to get any version at or after this rename.
Decided to take the jump from CVS to SVN.
I setup a new repository in subclipse for my project. When I go to 'Finish' the setup it wants to do an initial commit and presents me with a flat list of files to select the files for version controlling.
The problem is I have thousands of generated binary files I dont want to commit.
So I click on cancel because it would take me all day to go through and unselect all the unwanted files. Annoyingly when I click on a parent category for the files I want to ignore it is not recursive!
So I click cancel then go to the eclipse directory structure for the project and manually set svn:ignore on all directories I want to ignore. Then I try and do a commit again and all the files are once again presented - ignore seems to have done nothing.
Can anybody point out what I might be doing wrong?
For the first commit, I recommend writing a small script to delete (of course you'll have a backup) all the files that are not meant to be committed.
Afterwards, if you find you accidentally committed a file, you can
svn delete file
Upon the first checkout, copy back (or better yet, regenerate) all the binary files. This will trigger svn to notice that your local repository is out-of-sync with the remote repository.
cd <Root of local repository>
svn status
You will see lots of "to be added" items. Go to the parent directory and add in svn:ignore properties for each of the generated items.
cd build
svn propedit svn:ignore .
which will open an editor (if it doesn't, you need to set the environmental variable SVN_EDITOR to a suitable editor). Then you can add in entries that svn will know are not tracked.
(in the ignore property editor)
target
build
image*
*.o
(and so on)
Save the file, and it will be staged for the next commit. Subsequent runs of svn status will no longer show these files as "needing to be added", but they will show the directory as "needing to be committed (it's a revision on the directory)"
Quick Aside
So I'm not entirely certain exactly which functionality of Subclipse you were using in order to create a repo and share a project to it, I'm assuming you created like a file based repo through the eclipse SVN repo view and tried to share and then commit to it. It looks like your problem got solved but I did want to add an answer on here because I ran across this post looking for the answer to this same problem of handling initial commits even just in general with SVN and wanted to offer help to anyone else looking for the help.
Intro
To start off I would recommend not working through an IDE extension like this just for the initial commit as they can miss a lot of the options for handling opening a repo in SVN. I personally really like the command line form of SVN to work with but TortoiseSVN is a good option for a GUI.
Whether you create a local file-based repo or are connecting to an SVN server and you want better control over your first commit in an previously unversioned project here is what I've found as the best general workflow for doing so.
Create the remote folder to save to.
On command line this will be:
$> svn mkdir your-url-scheme://your-site-address.domain/path/to/repo/example-directory
Or on TortoiseSVN open your repo for browsing, right click, and select "create new folder"
This will give you a location in the SVN repo to checkout from for our next step.
Checkout in to the already started project
Make sure to use the empty, newly created folder in your repo to checkout with. SVN does not actually require a folder being checked out to to be empty, which is an important part of what makes it actually very flexible and able to subsume parts of your directory into it fairly easily if used correctly.
Now you will checkout this empty folder into the root folder of your already started project. This will add your project to the working copy of this folder without any commit being made yet. The command is:
$> svn co your-url-scheme://your-site-address.domain/path/to/repo/example-directory /your/projects/root/
"co" standing for checkout. In Tortoise svn you can right click on or in the empty repo folder and select "checkout..." and then select the project root.
Set ignores and commit
Finally, you can easily set your ignores on certain files before adding any other files to the tree using the command:
$> svn propset svn:ignore file-or-directory-to-ignore
And to add all non-ignored directories and files:
$> svn add * --force
The force is technically unnecessary in this case but ensures full recursion. You can also now do all of this in your file explorer if using TortoiseSVN or you can even use your IDE extensions to do this at this point(make sure to ignore all files you need to before mass-adding files for commit), all that's left is to make sure to commit the newly added files to the repo and you're up and running with source control :)
Added this method here simply because this method allows you to avoid any unnecessary copying of those stinky binaries that no one wants to lug around with them.
Using the combination of tools in the title, when I check out a branch, SourceTree/GIT will:
Definitely NOT delete folders from the previously checked-out branch, so if I have BRANCH-ALPHA with FOLDER1 and FOLDER2 and then I check out BRANCH-BETA which has FOLDER2 and FOLDER3 only and no FOLDER1, the resulting structure in FINDER will show that FOLDER1 is still there. Can reproduce this over and over.
Often will not even overwrite files from the previously checked-out branch, so that I'm still seeing BRANCH-ALPHA in Eclipse when I have checked-out BRANCH-BETA.
I close Eclipse before doing the checkout, and then open Eclipse, CLEAN and BUILD everything. It's really a problem with GIT.
The only "solution" is to delete all the folders and all the metadata and then check out the branch. This typically leads to a few hours of trying to "convince" Eclipse to open the project, creating a new workspace, new metadata, etc., and then fixing a lot of things like paths etc.
Any ideas on how to further research the cause and find a solution are very much appreciated.
Git only deletes empty folders when checking out a new commit. You might see apparently empty directories because there are hidden files stored in them. If you try to monitor the behavior by opening them in Finder, you're actually causing the problem since Finder creates hidden files to track the way the folders are displayed.
Does it really bother you that the folders are there? You could add a post-checkout hook that runs git clean -dxf after each checkout; this will remove all the files that are not known by git. Be careful that it will also delete compiled classes, so a new build will be required.
Another possibility is that something is locking files or directories, so git can't remove them while they're still opened/locked by the other program. This would also explain why some files aren't updated to the right version. Does git complain when you switch branches? It should if there's indeed a lock on the files.
I just spent a fair amount of time selecting the files and directories I wanted under version control. I'm running subclipse under eclipse. I right clicked, Team, Add to Version Control. Now I want ONLY those files committed without right clicking the whole directory which contains a huge number of media files that I don't want handled by version control. If I go Team/Commit under that directory it hangs for a very long time... I thought by "Add to Version Control" there was an option to commit those files only. I just don't know how to do it.
I hope I explained the question properly..
UPDATE:
Since people are talking more about ways to ignore files rather than committing what you're marked as "Add"ed to Version Control, let me put this a different way. What does "Add to version control" do exactly? It seems to be a feature without use.
Subclipse includes both unversioned files and files you specifically marked for addition when you open the commit dialog. It does not perfectly mirror the behavior of the command-line client. You have two options: uncheck each file you do not want to commit in the Subclipse commit dialog or use the command-line svn tool to commit. The command-line tool will only commit files you have marked for addition and will ignore the other files. Here's a simple example:
$ touch file
$ svn status
? file
$ svn add file
A file
$ svn status
A file
$ touch file2
$ svn status
? file2
A file
$ svn commit -m "Added empty file"
Adding file
Transmitting file data .
Committed revision 2.
? denotes a file that it unknown to svn and will not be put under version control automatically by svn commit. A denotes a new file that is scheduled for addition. Subclipse is trying to mirror this behavior by allowing you to "add a file to version control", which is the equivalent of the command-line svn add. but also includes unversioned files not scheduled for addition in its commit dialog (which I personally find somewhat annoying). If you run svn status on the command-line, those files which you "added to version control" in Subclipse will be marked with an A while those you did not will be marked with a ?. You won't have to run any svn add commands since you did that already in Subclipse.
You can add a pattern in Preferences/Team/Ignored resources (it's not the same as svn:ignore). You can also delete it, if it is no longer helpful.
use svn:ignore for the resources you don't need under version control (Team > Add to svn:ignore)