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.
Related
I completed MyProject1 and have uploaded it in git in fine way with commits after adding each new features. And now I'm starting MyProject2 and was trying to add the URL for the remote repository. But then I found out that I had mistakenly added the URL in Documents instead of MyProject1 folder because of which MyProject2 folder is also being tracked in MyProject1. And I'm not being able to add URL to MyProject2 but instead facing merge issues.
Is there any way to detach the track from my Document folder without deleting any of my files from Documents.
Structure is this way(I'm using Linux):
Documents
(And inside Documents there is:)
MyProject1
MyProject2
And other folders which are also being tracked.
We can manually do it with below steps
create a file .gitignore in base directory.
If MyProject1 and MyProject2 are already part of git tracking, Please run commands
git rm -r --cached MyProject1/
git rm -r --cached MyProject2/
Open the file in text editor and add below lines in file
MyProject1/
MyProject2/
Best way:
Create a .gitignore file following #Vinayagam R
Ignore file locally
Those methods won't affect other contributors working on the same remote repository:
Use update-index:
If you want to stop tracking a file at certian point.
git update-index --assume-unchanged yourDirectoryName
--assume-unchanged is the flag which means the files should not change locally. In other words, it is used when ignore files that you do not need to change locally (or should not change).
To revert it use update-index --no-assume-unchanged yourDirectoryName
Using .exclude
In your working directory edit .git/info/exclude
I have tried to search for a way to resolve this and have come up with nothing so far.
I made changes to certain files in a directory. I then performed an svn add and svn commit for those files I changed. Then (by accident) I deleted the directory in svn containing the files I just modified. (the directory names were different which is what caused the mix up).
My goal is to get back the directory I deleted with my modified files or get back just the modified files. I have tried using svn merge -c REV and recommitting. it first told me there was a tree conflict with the directory i deleted so i did an svn resolve --accept working PATH. I have also tried an svn merge -r (current):(previous) to no avail.
Please help. I am using Linux (centOS)
I want to have all my configuration files versioned using Git in a remote repository at Github. I'm using Debian 7 testing, and all my configuration files are under the /home/user_name/ directory.
I created the usual .gitignore with all the files that I want to ignore and the files and directories that I want to allow versioning. My problem begins when I go to Documents, for example, and I see in zsh that folder is under the same versioning as the home directory.
I understand that Git works that way, but I need to know if it's possible to avoid that.
One classic way to version configuration files is to create a subdirectory like ~/etc/ and let your ~/.something files be symbolic links to ~/etc/something. Then, you can version ~/etc/ normally.
You can manage to ignore everything but your configuration files, but you'll always have little glitches like: the day you run git clean -fdx in the wrong place, you delete all your data.
Write */ in your .gitignore to ignore directories. Make exceptions with !foodir. Consider prefixing with slashes (see documentation for details).
I have a linux directory (and don't need any windows checkout):
/home/me/projects/project1
In this project, I need SVN (1.8.8) to follow a symlink "link1":
/home/me/projects/project1/link1/<some_directories_and_files>
But SVN won't let me do that, it just add link1 but not its content. If I try to add its content, I get an error:
svn add link1/*
svn: E145001: Can't schedule an addition of '/home/me/projects/project1/link1/first_directory' below a not-directory node
I tried converting link1 to hard link but I can't do that either:
ln /path/to/my/linked/directory link1
ln: ‘/path/to/my/linked/directory’: hard link not allowed for directory
Any idea? How do you handle this kind of configuration? I just need to commit everything from /home/me/projects/project1 from a simple svn commit
If I understand your problem, you have:
project1/
project1/link1 -> ../../some/where/else
If you do a simple svn add link1 it adds a symlink entry to the subversion repository, but what you're trying to accomplish is getting the stuff under somewhere else into the tree.
If this is the case, then you're fighting in the wrong direction, you should make the real files and directories under link1, and make the target locations symlinks into the link1 directory. That would be a simple solution to the problem.
Another solution would be to make the location ../../some/where/else an svn location in it's own right, and make link1 an externals definition to that location. When you commit in the main directory, the externals would be committed at the same time which would achieve storing the information; however to ensure that the other location was kept in sync, you would have to make sure to update it to the same version as the stored data.
In my case, on my desktop, I have a settings directory:
$HOME/settings
This is a checked out copy of a directory containing .bashrc, .profile, .vimrc, .vim, etc. files and folders from an svn repo. All my profile files and directories were symlinks into this folder, so for example .profile -> settings/.profile, etc. When I make changes, they are reflected in the svn tree, which I can commit back to in order to ensure that I don't lose my config settings when I go to another system.
If you really want svn to follow symlinks as hardlinks (You can't make directory hardlinks because it would be a bad thing™), then you'll have to hack the svn client source so that it did what you wanted; but this would be a maintenance nightmare.
You could get away with making the symlink into a bind mount point directed at the target, but that has it's own issues - you would need to be root to accomplish this, and it ends up leaving funny entries in your /proc/mounts to accomplish this:
mount --bind /absolute/path/to/some/where/else project1/link1
Bind mounting does not work when mounting to inside the svn tree since the working copy format changes introduced by svn 1.7 - svn operations attempt to move files from .svn/tmp to the target folder, which would be a cross device link. The workaround in this case is to go from the inside out, i.e.:
mount --bind project/link1 /absolute/path/to/somewhere/else
With the change in the svn working copy format of a single .svn folder for the checked out tree, you will need to perform all subsequent operations from the true svn location, as it won’t work from the bind mounted folder, on the assumption that you have not mounted the entire checked out tree at that target location.
I have added an exclusion to my workspace which is called "dev-machine"
-//depot/DotNetProject/bin/... //dev-machine/bin/...
The bin folder now shows as excluded in p4diff but...
The differences are still showing i.e. diff 1 of 11 and the next and previous arrows are still taking me into those excluded folders.
Am I missing something obvious here?
Did you add the client-spec rule to remove the bin directory after making changes to the directory, and opening files in the directory? Perforce will still consider the files as mapped until you explicitly sync, and even then it'll prevent you from removing the file Perforce knows is open.
If Perforce already thinks the files in the bin directory are open (check with p4 open), your best bet may be to force-sync these files, or revert them, to remove them from your workspace. You'll end up with no files in your bin directory (at least, that Perforce is tracking), so you'll need to rebuild.