during synchronisation with the CVS server, eclipse compares the content of the files (of course it uses internally CVS commands). But files without any content change are also shown as different, if they have another timestamp, because they are "touched". You always have to look manually per file comparison dialog if there was really a change in it or not.
Due to auto-generation I have some files that always get new timestamps and therefore I always have to check manually if they really contain any change.
At the eclipse docu I read :
Update and Commit Operations
There are several flavours of update and commit operations available
in the Synchronize view. You can perform the standard update and
commit operation on all visible applicable changes or a selected
subset. You can also choose to override and update, thus ignoring any
local changes, or override and commit, thus making the remote resource
match the contents of the local resource. You can also choose to clean
the timestamps for files that have been modified locally (perhaps by
an external build tool) but whose contents match that of the server.
That's exactly what I want to do. But I don't know how!? There is no further description/manual ...
Did anybody use this functionality and can help me (maybe even post a screenshot)?
Thanks in advance,
Mayoares
When you perform a CVS Update on a project (using context menu Team->Update), Eclipse implicitly updates the timestamp of local files whose contents match that of the server.
Related
When you right-click > index on a project there are a few options:
Rebuild
Freshen All Files
Update with Modified Files
Re-resolve Unresolved Includes
I've been just hitting rebuild everytime but now I'm working on a huge project and can't afford to do that; when I modify a file, whether it's a .cpp or .h, I need to know which 'index' operation to do.
For each of the 'index' options:
What does it precisely do?
What is the cost (relative memory, CPU time)?
Documentation from Eclipse would be helpful but already searched and didn't find any.
Rebuild can only be performed on the whole project. It throws away the project's entire index and rebuilds it from scratch, indexing each file in the project.
Since it starts by throwing away the previous index, cancelling a Rebuild will result in an empty or partially built index.
The other actions can be performed either on the whole project, or on a folder or file (or group of folders/files) in the project.
They all go through the files in the selection, and update some or all of them in the index. Unlike Rebuild, they do not start by clearing the index, so cancelling them is relatively safe.
Freshen All Files updates all files in the selection. If called on the project, the end result is comparable to Rebuild.
Update with Modified Files only updates those files in the selection which have changed since the last time they were updated in the index, as determined by their timestamp and a hash of their contents.
Re-Resolve Unresolved Includes only updates those files in the selection for which configuration info (such as specified include paths) has changed, and the change resulted in an include that was previously unresolved now being resolved.
The performance characteristics can vary a lot depending on the project size and the kind of machine you're running on. I work on a very large project (millions of lines) for which a Rebuild can take 20-30 minutes on a relatively modern desktop. The operation is typically CPU-bound, but the indexer is currently single-threaded, so it will only use up one CPU core.
Finally, I'd like to mention again what I said in my comment on the question: if you configure the index to be updated automatically in Preferences | C/C++ | Indexer, you shouldn't need to manually invoke these commands at all, at least in theory. In practice, I find an occasional Rebuild is necessary (say once every few weeks), especially after a configuration change (e.g. adding a new include path).
Sources: this mailing list post, reading the implementation of the actions, and experience using CDT.
On my project I have some files that are generated automatically, so you'd normally don't put those in Source Control.
But since this process takes a long time and they change quite periodically, I'd rather keep them in Clear Case database to not impose this process to every one that desires to compile the source that isn't directly related to these files.
So, is there a way that I could add files on ClearCase UCM without creating a version tree?
More directly, I'd like to know if there a way to only one version per branch. As if when delivering this file to the main branch, it would delete the old version an replace it by the new one.
I know that this is a bit unorthodox, but I ask this because I'm not interested by the generated files history and I'd like to save space in the server.
So, is there a way that I could add files on ClearCase UCM without creating a version tree?
No.
Unless those files are radically different from one generation to the next, (or are huge binary), ClearCase would only record the delta, which wouldn't consume too much space.
One trick would be to rename the stream in which the import of the newly generated source is done, and create a new stream, in order to not have a huge version tree over time.
hg record is very useful for splitting the changes in your working copy into multiple commits.
When you run hg record, it will ask you for each modified file:
examine changes to '<file>'? [Ynesfdaq?]
and if you say yes, then for each change in the file:
record change X/Y to '<file>'? [Ynesfdaq?]
However, I often find that I could complete the operation much more efficiently by automatically being shown all changes (i.e. as if I said y to every question of the first form). Basically, I want to see all changed hunks and make yes/no decisions about them, without the distraction of intervening examine changes to <file>? questions (to which I would always say yes).
Is there to get hg record way to do this?
I find the CRecord Extension invaluable for this. It gives a curses based UI for the record command, and allows you to get a much better overview of all your changes. It also allows you to select down to line resolution, rather than just each hunk.
I am using CVS as version control system and facing a strange issue. For some files, I am not able to synchronize or update (using eclipse) because of the following error:
"[Project Name]: cvs [update aborted]: cannot create .#lang_en.properties.1.1.2.3.2.7.2.2.2.3.2.1.2.1.2.3.8.1.2.4.6.12.2.3.4.1.4.3.2.6.2.13.4.4.4.1.2.9.2.2.2.1.8.1.8.1.14.1.8.3.26.1.8.1.4.4.6.17.4.2.6.6.6.3.2.2.2.2.10.2.2.2.2.2.2.9.2.7.2.1.4.10.4.2.2.3.4.4.2.2.2.1.2.1.10.2.8.1.6.1.4.1.4.2.6.1.2.1.2.2.4.5.4.1 for copying: File name too long"
According to my observation this happens with frequently committed files. What happens is someone in the team commit such a file (which works) but then when some other person in the team try to sync or update, it simply shows 'file name too long' error. I would like to clarify that in example above file name is only "lang_en.properties'.
I am not sure how to resolve this issue. I have even tried deleting file from cvs and then recreating with same name (that is required), but same revision history appear again. Any help would be appreciated.
A file named like .#<filename>.<revision> is created when you do a cvs update and there are changes made to your checked out file. This is effectively a backup of the version you had, in case the update did something that you didn't want (eg. introduced a conflict that you are having trouble resolving). This allows you to roll back an update.
The simplest way to address this is to remove the local file before doing an update. That way there is no need for CVS to create this backup file.
According to my observation this happens with frequently committed files.
This is not caused by frequent commits. The revision id will increase sequentially every time you do a commit. eg. 1.1 -> 1.2 -> 1.3 and so on. Extra digits are added when you do branching. For example, if you took a branch off the 1.3 version of the above file then the revision numbers would be 1.3.1.1 -> 1.3.1.2 -> 1.3.1.3 etc.
I don't know how you are working, but your project seems to have introduced an impressive level of branching. Until you address that workflow, you are going to continue coming across this problem almost every time you attempt an update. You have hit the 256 character filename limit which exists on a lot of file systems.
How are you doing this task in Perforce ?
Yes, you can't do that.
The only thing you can do would be:
shelve your file without reverting it
open the diff of your file, and remove any other changes that those you want to submit
submit the resulting file which contains only the part you wanted to
unshelve the shelved version of the file
get the latest revision of it, and resolve (P4 should be able to auto-resolve it)
Then you still have the file in checkout, with the other modifications.
You can't. As with some other version control systems, you operate on a per file basis. That is, a single file is the smallest entity / unit of work possible.
I'd think that they all act on the presumption that changes to a file are atomic (most good version control systems will even use a commit of multiple files as an atomic operation).
If you only want to commit some parts, you essentially have to create a copy of your modified file, where you reset all those parts that you don't want to change back to their original content/text. Or better yet, only change one thing at a time and eventually separately commit those changes.