After a fresh checkout, I want to get ALL files,
specifically this file: etc/config.ini
However, once I modify etc/config.ini, I do not want it committed with "svn commit ..." nor should it be reverted on a "svn up".
This would allow you to get default values on an initial checkout (convention over configuration), but then after configuring, you don't want these "local" configuration files committed into svn.
The best way to do this is not to directly version control the file.
A common way to avoid this issue is to have config.ini.sample (or something along those lines) under version control, and then config.ini ignored in your svn:ignore property.
Then, after checking out, copy config.ini.sample to config.ini and you're good to go. This way you can also version control your template config file.
If you use TortoiseSVN and/or VisualSVN (>= 1.5), you can move these files to the changelist 'ignore-on-commit'. This causes the files to show up in a separate section in the commit dialog, and never automatically selected for committing.
Obviously this is a TortoiseSVN-specific solution.
Jason already hit on the general accepted solution (the one promoted by the SVN folks themselves), but there is another option, if you're using TortoiseSVN as the client. When you're at the commit dialog, right-click the file you don't want to ever commit and choose Add To Changelist->Ignore On Commit. It will still show up in the commit dialog every time you go to commit it, but it defaults to unchecked so it won't actually be committed unless you explicitly check the box. Again, only useful for Tortoise, so if you use the same WC with a non-Tortoise client, you'll accidentally commit it.
Related
I have a file "db-connection.php" that has to be different for each version of my server. (Localhost, Dev and Production). At first I thought .gitignore was the answer, but after much pain and research, I realized that .gitignore only works on untracked file: e.g. files NOT already in the Repo.
For obvious reasons, the localhost version I'm using with xampp requires that the db file be within the repo. Of course, this means that every time I push it to Dev, it ruins the Dev db connection.
Is there a way to tell .git "Yes, I realize this file exists, but leave it alone anyway"?
This is a common problem, and there are two solutions, depending on your needs.
First, if you always are going to have the same configuration files and they will change depending only on the environment (but not the developer machine), then simply create the three versions of the file in your repository (e.g., in a config directory), and copy the appropriate one into place, either with a script or manually. You then remove the db-connection.php file and ignore it.
If this file actually needs to depend on the user's system (say, it contains personal developer credentials or system-specific paths), then you should ship a template file and copy it into place with a script (which may fill out the relevant details for the user). In this case, too, the db-connection.php would be ignored and removed from the repository.
There are two things people try to do that don't work. One of them is to try to keep multiple branches each with their own copy of the file. This doesn't work because Git doesn't really provide a way to not merge certain files between branches.
The other thing people try to do is just ignored the changes to a tracked file using some invocation of git update-index. That breaks in various cases because doing that isn't supported, and the Git FAQ entry and the git update-index manual page explain why.
You can use the skip worktree option with git-update-index when you don't want git to manage the changes to that file.
git update-index --skip-worktree db-connection.php
Reference: Skip worktree bit
Right now I'm manually selecting each changed file for staging before committing. I'm curious whether there's a SmartGit equivalent to
git commit -a
perhaps a shortcut to select all changed files (other than those being .gitignored).
When having selected the repository root directory in the Repositories view and having the focus in this view, operations like Stage and Commit will work on all available files, regardless of which files are currently visible in the Files view (e.g. you might have selected to hide untracked files).
You can select all changed files in the Files pane with standard OS shortcut. On Windows this is Ctrl+A. Then you can stage the selection as usual.
Note though that if you are going to commit only the whole files, you don't even need to stage them. After you selected files of interest, you can press Commit, and then make sure the "Local Changes" option is picked on the top of the dialog. SmartGit will stage and commit selected files for you automatically.
We use ClearCase as control version system.
In our system sometimes we make releases without some developers commits because of time limit.
For example I made some changes in six classes but another user did changes in all or some of them also. And I have to commit code without his changes. So I scan my files with previous versions so that I can revert his changes. But it's a slow and boring process.
Is there another way to do that? Maybe an extension or a script?
The only way to automate that process is through:
subtractive merge or negative merge (as described in this IBM article):
cleartool merge -to filename -delete -ver \main\branch\version_number
cset.pl, which can take all the checkins of an UCM activity and cancel them.
See "Clearcase: how to rollback all changes on specific branch?".
But this is for UCM (which might not be your case)
In both cases, the idea is to create a new version which cancels the version of your other developer.
While at home for personal projects i use Mercurial, at work we're using ClearCase.
I am attempting to run a few horizontal (touching lots of source files) refactorings in Visual Studio for the code base, however, for since each file is locked by ClearCase, it has to be unlocked and prompts for the actual activity that the check out is for.
In Mercurial, there's no such concept as far as i'm aware of: files are not being locked at all at any point of time!
Is there a way of doing such a refactoring, or any other operation that acts on multiple files, without having to check out each and every one manually?
In a DVCS (distributed VCS like Git or Mercurial), you simply cannot "lock" a file, since all the other repos wouldn't be aware of such a "status".
But with ClearCase and its locking mechanism (optimist with "unreserved checkout" or pessimist with "reserved checkout"), you need to make a checkout to tell ClearCase you will modify some files.
However, you could also, for large refactoring:
make and update a snapshot view
set all the files as writable (through an OS-based command, not through ClearCase "checkout")
perform your changes
search for all hijacked files and checkout/checkin those files then
I'm looking at a scenario where I have an offline clear case view and I modify files in this view clearing the read-only attribute (hijacking) on the files I modify then several days later I take the view online and need to get my offline changes into the stream.
What I would do is check out the hijacked files and check them back in (merging when necessary).
Is it always safe to work this way?
Is it possible that while adding my changes I would accidentally overwrite other people's changes done while I was working offline?
Any recommendations on how to use ClearCase offline?
Thanks!
(I'm asking because a college says that this offline way of working can lead to overwriting other's changes, specifically in cases when one updates ones view after working offline for a while before converting the hijacked files into checkouts. He says it won't event propose to do a merge in some cases, just completely overwrite the contents of the element being converted with the contents of the hijacked file)
No you won't override anything while working offline.
ClearCase has a reconcliation mechanism for a snapshot view, which, when you get back online, will allow you to:
search for all hijacked files
checkout those files
then checkin them, which is when ClearCase will prompt you for a merge, if any new version has been done on that file during your time offline.
That merge will be a three-way merge with:
root version: the version before any modification by you or other
source version: the matest checkin version (done while you were offline)
destination version: your current file
What about setuping a private branch, working on it, hijacking there files and then merging your private branch on the main branch?