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.
Related
TortoiseSVN 1.93
Thought something was odd when I went to commit some changes, as one of the files I had added earlier was not showing up. One in particular is a .cs file in a class library project. I thought this was odd, so I added a dummy test.txt file and then started a commit again, and even that text file was not in the list of unversioned files.
Usually, if there are unversioned files, I will see them and can add them right from the commit dialog. There doesnt seem to be anything in my ignore list that would prevent these files from showing up. However, if I check for modifications, and choose the "Ignored" checkbox, sure enough, both of those files are in the list, among others.
Whats going on here?
Here is my ignore list:
bin obj debug *.o *.suo *.lo *.la *.al .libs *.so .so.[0-9] *.a
*.pyc *.pyo pycache *.rej ~ ## .#* .*.swp .DS_Store [Tt]humbs.db
Checked the SVN properties on the folder where these files were located, and there was an svn:global-ignores property set to reference the entire folder. Removed that, and opened a commit dialog again and those files were listed. So somehow, I must have got a little too ambitious with setting things to be ignored.
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 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.
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.
In a Mercurial repository, how to find lastly committed 10 files contained in a subdirectory? I want to do so because I'm a little worried that some files are mistakenly committed.
Using revsets is probably the best approach.
A close approximation may be hg log -r "last(file('subdirectory/*'), 10)".
This command returns the last 10 commits that touched any file in subdirectory. From there, you could review each commit for the files affected.
If --template "{files}\n" is added to the command, it will list the files touched in each of the commits. However, the list would include files outside subdirectory as well. See hg help templates for details.