In our company we are using git.
If I have some file which isn't there and I run command gitk, I can see red dot with description:
Local uncomitted changes, not checked in to index
Now I create new repository in GitHub because I want to work with this tool more efficiently.
But here when I have some file which isn't committed, I can't see any red dot when I run gitk.
Is there some option how to set this ?
That can happen, as described in this thread, when:
You are on a case-insensitive file system.
The linux kernel source requires a case-sensitive file system because the sources contain both of these files:
include/linux/netfilter/xt_connmark.h
include/linux/netfilter/xt_CONNMARK.h
Since GitHub is on a case-sensitive filesystem, it won't be affected by this issue (hence no "red-dot").
Related
In my development team we use requirements management to control the expected behavior and functions of our products and a bug report tool to track 'problem reports' (PR). Any change in the requirements is done by a 'change proposal' (CP) which acts much like a commit on a code repository.
In order to make any commit that changes the final product one must supply on the CVS commit commentary a trace which can be either a CP (this means that the change on your code reflects a change in the product) or a PR (which means the changes in the code are being made to correct a problem). CPs and PRs are numbered so that one can link changes in code to the causing item (CP or PR).
Sample commentaries
Error correction commit commentary:
Kind: Error Correction
Trace: PR-015 Crashing upon startup
Description: Edited file foo.c in order to verify uninitialized variables.
Product change commit commentary:
Kind: Development
Trace: CP-053 New login mechanism
Description: Added login mechanism with library X and blablabla.
My problem here is that I don't have any easy way of retrieving all the files that were changed for a specific CP or PR neither can I retrieve all the changes made to the code.
I have tried to use regexp (RE from python) in order to parse the log but it has been a little tough to cover all possible logs. My regular expressions failed to retrieve the list here and there even after adapting it some times.
So, I've been thinking if there isn't any easier way or any project or product or even a CVS built-in feature that might help me here.
The objective question: How do I retrieve the list of modified files in a commit which is identifiable by a well-formed tag (the CP or PR)? Is there an easier way or should I stick to log parsing?
Environment details:
OS: Windows XP
CVS server: cvsnt
CVS client: tortoise / cvsnt
Didn't want to answer my own question but I think it may be helpful for future reference for people with the same problem.
Well, I managed to perform a search within the 'log messages' (cvs term for the commit commentaries) filtering by the content of the text in the log message and group the files changed on that commit.
As pointed out by 'Joakim Elofsson' here, cvsps is a good tool for grouping commit information in 'patch sets' which are individual commits with references to all the files changed in those commits.
I used the version of cvsps packed for cygwin as at this moment there's no port for windows.
Just install the cygwin with the internet setup available here and, when choosing packages, search for cvsps and cvs, install both.
I couldn't manage to use the checked out files on my system (through the /cygdrive/c folder) so I checked them out from the cygwin shell.
BEGIN Obs for tortoise users
You'll need to setup CVSROOT environment var to the current CVSROOT of your repository by the command:
export CVSROOT="Your CVSROOT string here"
Usually, if check the properties page of any file of your checked out code base there will be a tab named CVS. There'll be your CVSROOT string. (if you're using :sspi: to connect to your remote repository as I do, you may try to switch it to :pserver:, it did work for me but I don't know exactly why).
END Obs for tortoise users
Well, after checking out your repository use command:
cvsps
This will create the cvsps patchset base for your requests. Then use:
cvsps -l "Some regexp code"
It will search the patch sets for log messages matching the input regexp.
This is a sample from using cvsps -lP100-PR-FEX` on my database (changed some filenames and paths for being able to make it public...):
PatchSet 71
Date: 2012/10/25 11:30:44
Author: GUARITA
Branch: HEAD
Tag: (none)
Branches:
Log:
Kind: Error correction
Trace: P100-PR-FEX145
Description:
Corrections of the TRUE and FALSE conventions used by the C++ (true:everything but 0, false:0) P100 interface to the VB6 (false:0, true:-1 or 'all bits set to 1 which is -1 in 2's complement') P100Interface ActiveX object.
P100 Panel Version increment.
Members:
SidePanels/P100.wimp:1.2->1.3
SidePanels/Calcs/P100Interface/private/P100Interface.cpp:1.2->1.3
You may also use it to compare changes between tags (which I use to control releases) with cvsps -r <tag1> -r <tag2>.
I have already used some VCS like CVS, SVN and Git. One feature that I am missing cannot be found anywhere.
There are files which I would like to have in the repository but every user should have its own. So when you checkout you get a default of that file and that commit your changes only for yourself.
Why do I want this? There are some files like configuration where I would like to have a default version in the repository (e.g. for building releases or a starting base for new team members) but the changes to that file are only relevant to a certain developer (or working copy) because it will contain paths only valid for that developer/working copy.
Currently when I do not add this files:
- I miss them when creating a new working copy or exporting for a release build
- Have no history which changes I might have done for myself for experimenting
Currently when I add this files to the repository:
- I might never commit them so I have a default in the repository but my file is always flagged "changed". In SVN I can add it to the "ignore-on-commit" changelist to improve a bit.
- I might loose my very own changes of a difficult configuration file (data crash, laptop theft, etc.)
Is there a VCS capable of this? Do SNV or git support something regarding this I might have overseen?
If I understood and decomposed your task correctly
"Have a set of default templates of something, which are starting point of per-user customization and these customized versions must be stored separately and be accessible only by responsible person"
you can use this workflow (draft, subject of modifications and corrections), Subversion based for simplicity and transparent management (strong point of any CVCS really)
Subversion repository
Each user of repo have own predefined path inside repository-tree (with common path-pattern for manageability and easy automation of processes)
One special admin-only managed path also exist, not accessible by ordinary users
Our tree may seems like this (where Repository dir is a root of repository)
z:\>dir /s /B
z:\Repository
z:\Repository\Users
z:\Repository\Template
z:\Repository\Users\Alpha
z:\Repository\Users\Bravo
For every user-path we use Path-based Authentication, which provides access for every and each user only to own subtree in repository,
Template contains (as name assumes) templates stub for all user's documents
Adding new users to repo, obviously, becomes simple and easy automated task:
svn copy Template into new user's dir
add rw permissions for created location for user in authz-file
tell user URL of his personal tree in repo
I don't think the VCS is the problem here. It looks like if you have a file whose contents are dependent on the local environment, you should auto-generate it with a script. This way, you ignore the generated file, but version the script and each developer still gets a perfectly valid copy of the config files at run time. This is the same approach that is used, for example, with user specific IDE settings: .suo files on Visual Studio for example.
Update:
If you specifically need a set of defaults, then the solution is this:
Add the defaults to the repository.
Each dev works in their own branch. This way, they can version the
changes to the config files.
When re-basing onto master and/or merging, the devs simply never
merge their customized configs.
You can always set up a hook to check if the default config has been modified, and if so, maybe email the dev. You simply view such a commit the same as you would view a commit that does not compile.
Devs are smart. Sure, they make mistakes. But never under-estimate the power of some simple communication.
Of course, when the default configs do get overwritten with the customized ones of Dev X, then you use the powers of git to fix that commit immediately.
Our build person was having issues compiling some source code that is checked into our TFS instance.
I was working on some changes that I was not ready to check in so I made a manual backup of my local folder and deleted the contents of my local folder. Then I did a "Get Latest - Specific Version , with overwrite" to ensure I got the latest. And made sure it compiled (it did, the issue was a setup issue on the build machine).
So now if I manually rename folders locally to go back to my version I have the problem that TFS thinks I have all the latest source ... which I don't. Files were changed by another developer but since I did a "Get Latest - Specific Version , with overwrite" it considers my code to be completely up to date.
Questions:
Can some how 'tell' tfs that my local versions are not that latest?
(I'm thinking that I might to do this with a TFS cmd line util but not really sure which one)
Was there a different way I should have done this?
Thanks.
You could delete/remove your local workspace.
Source Control Explorer -> Workspace dropdown -> Workspaces -> Remove
If you get specific version of Changeset "1" of your source code, TFS will delete local files, and will believe that you no longer have the latest code in your workspace. Then, when you do a get latest it will actually get the latest.
In future, instead of making a manual copy, create a shelveset. In the "pending changes" window, click "Shelve" and follow the dialogue (in this case you'd not want to keep your pending changes locally). This puts your work on the server in a secure, recoverable place, but without checking it in.
Alternatively, in the workspace dropdown, you can create a second workspace. That gives you two separate copies of the code locally, but also two separate sets of checkouts. This is really useful if you often find yourself interrupting one piece of work to look at something else.
If you do another "get specific" with overwrite, this should still fix your problem.
Do you know which files are changed? Are we talking a lot of files? Or just a few?
If it is just a few, then you should just copy your changed version back in then re-checkout the files. TFS will then register than you have changed those files.
If you have a lot of changed files then I recommend you give the Team Foundation Power Tools (tfpt) Online "Command Line" command a try.
The Command Line Help can be seen here.
Here some more info from Buck Hodges:
Online
With Team Foundation, a server connection is necessary to check files in or out, to delete files, to rename files, etc. The TFPT online tool makes it easier to work without a server connection for a period of time by providing functionality that informs the server about changes made in the local workspace.
Non-checked-out files in the local workspace are by default read-only. The user is expected to check out the file with the tf checkout command before editing the file. When working in this
When working offline with the intent to sync up later by using the TFPT online tool, users must adhere to a strict workflow:
* Users without a server connection manually remove the read-only flag from files they want to edit. Non-checked-out files in the local workspace are by default read-only, and when a server connection is available the user must check out the file with the tf checkout command before editing the file. When working offline, the DOS command “attrib –r” should be used.
* Users without a server connection add and delete files they want to add and delete. If not checked out, files selected for deletion will be read-only and must be marked as writable with “attrib –r” before deleting. Files which are added are new and will not be read-only.
* Users must not rename files while offline, as the TFPT online tool cannot distinguish a rename from a deletion at the old name paired with an add at the new name.
* When connectivity is re-acquired, users run the TFPT online tool, which scans the directory structure and detects which files have been added, edited, and deleted. The TFPT online tool pends changes on these files to inform the server what has happened.
To invoke the TFPT online tool, execute
tfpt online
at the command line. The online tool will begin to scan your workspace for writable files and will determine what changes should be pended on the server.
By default, the TFPT online tool does not detect deleted files in your local workspace, because to detect deleted files the tool must transfer significantly more data from the server. To enable the detection of deleted files, pass the /deletes command line option.
When the online tool has determined what changes to pend, the Online window is displayed.
Individual changes may be deselected here if they are not desired. When the Pend Changes button is pressed, the changes are actually pended in the workspace.
Important Note: If a file is edited while offline (by marking the file writable and editing it), and the TFPT online tool pends an edit change on it, a subsequent undo will result in the changes to the file being lost. It is therefore not a good idea to try pending a set of changes to go online, decide to discard them (by doing an undo), and then try again, as the changes will be lost in the undo. Instead, make liberal use of the /preview command line option (see below), and pend changes only once.
Preview Mode
The Online window displayed above is a graphical preview of the changes that will be pended to bring the workspace online, but a command-line version of this functionality is also available. By passing the /preview and /noprompt options on the command line, a textual representation of the changes that the TFPT online tool thinks should be pended can be displayed.
tfpt online /noprompt /preview
Inclusions
The TFPT online tool by default operates on every file in the workspace. Its focus can be more directed (and its speed improved) by including only certain files and folders in the set of items to inspect for changes. Filespecs (such as *.c, or folder/subfolder) may be passed on the command line to limit the scope of the operation, as in the following example:
tfpt online *.c folder\subfolder
This command instructs the online tool to process all files with the .c extension in the current folder, as well as all files in the folder\subfolder folder. No recursion is specified. With the /r (or /recursive) option, all files matching *.c in the current folder and below, as well as all files in the folder\subfolder folder and below will be checked. To process only the current folder and below, use
tfpt online . /r
Exclusions
Many build systems create log files and/or object files in the same directory as source code which is checked in. It may become necessary to filter out these files to prevent changes from being pended on them. This can be achieved through the /exclude:filespec1,filespec2,… option.
With the /exclude option, certain filemasks may be filtered out, and any directory name specified will not be entered by the TFPT online tool. For example, there may be a need to filter out log files and any files in object directories named “obj”.
tfpt online /exclude:*.log,obj
This will skip any file matching *.log, and any file or directory named obj.
I'm using a hack with opening the solution without network connection (unplug cable, turn off wifi) and solution will be opened in offline mode.
There is also a plugin called "go offline" for that.
And then, you click on "go online" which is automatically displayed, in case of offline solution.
After this, VS will check all your local files against TFS and automatically checkout files which were changed.
But for your case, I would also suggest to use shelvesets.
in TFS 2013+ and VS 2015+ you have Cloak option which deletes local files and cloaks those branches from getting downloaded to your local workspace (basically unmaps specific branches)
I am working on a project that depends on external programs, and needs to know the paths to them. I develop and use the project on several machines, using mercurial for version control. The paths are machine-dependent, so I keep them in a machine-specific config file. I would like the config file for each host to be version-controlled, but I need to ensure that the config file from one host would never overwrite the config file for another host when pushing or pulling between hosts. Is there any way to accomplish this?
In principle, Wim is right: machine specific configurations shouldn't be part of the project's source control. As long as you walk alone, this isn't a real problem, but once you want to provide generic releases of your project, you have to get rid of them. In that case you might not be happy about the fact, that the change history contains files with machine specific data.
Nevertheless, it may make sense to have machine specific data in version controlled files (personally I do this for my dot-rc files and shell scripts). In that case I would suggest to separate generic and specific configurations into different files and include/utilize the specific one at build- or runtime, depending on the currently used machine.
If it is not possible to detect the current machine automatically, you could still create an unversioned symbolic link on each machine, pointing to the appropriate specific configuration file. For instance, on the machine foo the file layout could look like this:
generic.conf version-controlled
specific-foo.conf version-controlled
specific-bar.conf version-controlled
specific.conf → specific-foo.conf unversioned symbolic link
An alternative to symbolic links is to use a hook which automatically creates specific.conf, e.g. on each invocation of hg update. As hooks are set in a repository's hgrc file, it can be defined individually on each machine. Here's an example of a corresponding hooks section in the .hg/hgrc file of a repository clone on the machine foo:
[hooks]
update = cp specific-foo.conf specific.conf
Machine specific configuration settings should not be version controlled in the same repository as the project code.
However, it is still a good idea to put an inactive sample configuration file in your code repository. And this sample could show a bunch of typical locations for the external program paths you mentioned as lines that are commented out. That way you make it easier to get your project running on new machines.
I am using Eclipse and Subversion for Java development, and I find myself wishing for a feature in version control systems (one that is not available in SVN, to the best of my knowledge).
I would like my project settings files to be half-ignored. To be more precise, I want them to be available in VCS, I want merge to occur when someone checks in changes, but. I want my own changes ignored unless I very explicitly tell the system to take them.
This would allow me to have my local paths (and other settings) in my local configuration w/o screwing up other people's configuration. But, when I have a substantial change, I can still check it in (very very carefully, may be temporarily removing my other local changes) and have it delivered to other people.
Now, the actual question: is there any VCS that supports this feature? Or may be I am missing something in SVN? How do other people solve this problem in Eclipse?
Yes, Git support that feature through filter driver (a clean script can run upon commit, allowing you to clean the content from any of your changes if you want).
But another way would be to never version that setting file, and only version:
a template file
a value file
a script able to replace variables in the template files with the values from the value file, in order to generate the actual (and "private", as in "not versioned") setting file.
That way, you can modifying it at your heart's content without ever committing your changes.
.gitignore for git, .hgignore for mercurial and file paths and patterns can be added that will not be committed. There similar in SVN but i never worked out how to use it myself but my sysop did set it up form me.
git supports this with
git update-index --assume-unchanged <file>
and the complementary
git update-index --no-assume-unchanged <file>
See http://blog.pagebakers.nl/2009/01/29/git-ignoring-changes-in-tracked-files and http://kernel.org/pub/software/scm/git/docs/git-update-index.html#_options for more details.