when I was checking the latest difference in code in SVN Log, accidently I clicked blame differences insted of show differences. Now, when I check the log again I do not see anything visible related to my blaming.
Do you know what exactly happens when you blame a difference? Does it effect the repository and if yes, how can I undo that?
My understanding of blame, is that it shows you who last modified a given line in a given file so you can determine which person to blame for that change. It does not change anything on the server side.
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.blame.html
In short: blaming shows you, who made which changes were to a file. Ususally the last changes will be shown for a given file for a simple blame report. If you choses to show the blame for a diff of two revisions, you will get the diff of the blame reports for the changes.
But there is no change in the repository.
Take a look at chapter
4.23. Who Changed Which Line?
in the TortoiseSVN help file.
Related
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.
I typically like to type up my git commit messages while looking at the git diff.
I very much enjoy the output produced by this little perl add-on to git, and produces output that looks like this from git diff (this is a screenshot of git log -p but you get the idea:
Because of how it highlights out the corresponding parts of the lines that have changed it is very easy to see what's changed. Just wanted to share that because it does not look like a lot of people use it, and for me it beats the hell out of using an external separate diff tool or something like that, because this works over the terminal! It is also quite more unix-pipe-friendly in general than something like vimdiff though vimdiff is quite handy in a pinch as well.
Anyway, the show-and-tell is only tangentially related to the real question here, which is, can I set up a terminal window where I've got the git diff showing, but to have it be dynamic so that when I save a file it can refresh the git diff for me? Basically the idea is to have a terminal window serve as a real-time display of the exact changes I am about to commit, and this way I can just switch straight from my text editor to entering the git commit command while reading the entire set of changes, and to have this workflow also be a possibility on a Linux machine over SSH as well.
That would be a really awesome workflow, and I think a little bit of cmdline fu can get me there, but I'm not really sure where to start. It seems like OS X and Linux would require separate implementations. I found fswatch which might work for me, and apparently that is similar to inotify-watch on Linux. I shouldn't need to set this up on more than just my OS X dev machine, but like I mentioned before, having this capability over SSH would be epic.
Are there any other quick-and-dirty UNIXy approaches to this problem?
You would like something like "watch git diff". The "watch" command repeatedly runs a command and shows the first page of output.
You need more than the first page of output, and also you don't want to be moved to the top of the output whenever it updates - you want to constantly view the same offset in the diff until you scroll.
I haven't tried it but you might be able to use "screen" or "tmux" to provide a large virtual screen. (See https://serverfault.com/questions/50772/is-there-a-paging-version-of-watch.)
What's wrong with using plain built-in git commit -v which just shows you the full diff of the changes to be committed under the commit message? (And Vim highlights this diff just okay, with stock setup.)
I've checked out a copy of the SVN branch (my branch) locally to which I've merged from a different branch (which has a completely different folder structure). So basically there are a lot of deletions (of old files) and additions (of new files).
When I try to commit the merge to the repository (to my branch), Tortoise says
This commit is not recursive, and there are moved/renamed folders selected for commit. Such moves/renames are always performed recursively in the repository. Do you want to commit anyway?
Is it fine to proceed with this commit? If not, what should I do so that there's no problem?
Also, for some files that I've added, I've made changes after adding (if this affects the nature).
Found by Google how to fix it: press F5 in the commit window (not in the "warning popup")
See http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2831045 for details.
On 26.08.2011 22:39, Ryan J Ollos wrote:
For several months now I've been seeing the following dialog box appear when
initiating Commit. It frequently happens when attempting to commit following
a merge.
The thing I have noticed lately however is that if I Cancel and then
manually refresh the file list (F5), I don't see the message again when
initiating the commit a second time. The commit seems to succeed fine and
with no further problems.
The commit dialog monitors the working copy in a background thread for
change notifications. Such notifications are sent by the OS in case
files are modified/moved/renamed/...
If such a notification is received, the commit dialog first does a few
checks so it can drop most of them. If the notification indicates that a
file that is not checked and not visible in the commit dialog has
somehow changed, it switches back to non-recursive committing.
That's because if you have e.g. a file open in another editor and save
your changes while the commit dialog is open, then that file would get
committed as well even though you haven't checked it in the commit
dialog (it doesn't show up until you refresh the dialog with F5).
So if you see that warning dialog often, please check if there's another
tool/app running which modifies files in your working copy.
And as you noticed: if you hit F5, that 'non-recursive flag' is reset
because after a refresh, you see all the files again - even the ones you
modified after you started the dialog.
Stefan
I had the same issue but resolved it by reverting changes to files that I had marked to 'ignore-on-commit'
Once I reverted these files, then tortoisesvn was able to commit all the other files from the merge
Is it fine if i proceed with this commit?
No, your commit will ignore all changes in WC-tree and reflect only root-level changes (broken merge).
You made an error when checking out non-recursive initially. You can try to perform good, full commit using --depth infinity parameter in the CLI or find this switch in TortoiseSVN GUI.
svn commit --depth infinity . -m "Merge"
Also for some files that I've SVN-added , I've made changes after adding (If this affects the nature).
In my case that was exactly what caused the message to appear, even I unselected those files for the commit.
Ugly solution which only works safely if just a few files are affected:
Create a copy of the changed files
Revert the changed files
Commit the merge/reintegration
Copy the changed files back to the original place
Reminder to self: only reintegrate a branch if the target (trunk) is clean.
I just had the same issue. Instead of selecting all the files, I clicked on versioned and everything worked well. In my case, the option versioned selected all the files, so everything is ok now.
It looks like TortoiseSVN performs some kind of validity checking before calling commit. Good but the error message is very unclear.
When I faced this issue, I went back to using the svn command line to commit. Commit failed due to the reason that one of the folders was not up to date. After updating just that folder, I ran "svn commit" once again and it went through.
Edit: PS: Before you use try this out, make sure you do not have any files marked as "ignore on commit". "Ignore on commit" is tortoise specific and SVN commit picks these changes as well.
Just thought I'd post this because it worked for me...
The reason this happened is because I'd partially renamed one of the new projects I'd created and for some reason they all showed up as "Missing" on the commit screen.
After I removed the project and folder (which SVN had put a tick on) and put it back in as a new project again, suddenly all of the "Missing" had turned into "Added" and the commit ran fine without warning me of anything.
Hope this helps!
I saw this issue and the cause was a few added files not having the added status for no apparent reason. They were 'normal' even though the parent folder correctly showed as 'added'. I reverted those 'normal' changes and then manually re-did them. This made each added item show up twice in the commit list but it resolved the error and everything appears to be in working order now.
It didn't have anything to do with ignore-on-commit as in another answer, it just seemed like a bug in TortoiseSVN.
The problem could be, that your mergeinfo is deleted by someone or automatically, because the infos moved up in the tree. If you are gonna merge them in again, it will work for the moment. But all others will get problems with their not merged branches. SVN will loose some code and merge already submitted code again.
So reverting those files and changing them again could work, but you should not just commit the changes.
i don't know a option for tortoisesvn but u could use the command line
svn commit --non-recursive [folder]
thats sould work just as u like it to work
greeings
My problem is this:
Basically if I try to commit a change to SVN and the commit fails then all the files I have selected are lost or forgotten and I have to go back through and choose the ones I want to commit again.
This is hugely annoying and I've not been able to find a solution to it.
So, is there any way that I can get TortoiseSVN to return to the state it was in just prior to when I pressed OK? i.e. all my selected files and comment are restored.
I know I can get the comment back using the Recent Messages button so it would be really handy if I could also do something similar to get the file list state back to what I had too.
For TortoiseSVN 1.6:
Settings-Dialog->Dialogs 2->Reopen commit and branch/tag dialog after a commit failed
in TSVN 1.7, that option is enabled by default, and only available as Settings->Advanced->OutOfDateRetry
If that is something that happens often to you, you could use change lists in TortoiseSVN. It works like that:
You check for modifications in your files by using the menu entry TortoiseSVN > Check for modifications.
In that dialog, you select the files you want to commit together, and select from the context menu Move to change list > <new changelist>.
You enter the name of the change list and accept it.
In you commit dialog, you see now the files grouped by change list, so if anything goes wrong, that information is kept then.
If you change the same files again and again, you may check the check box Keep changelists so that you may use the change list for your next commits.
I've been using Tortoise SVN + Visual SVN for about a year since left the corporate world to do my own startup. There's one feature in Tortoise SVN that I've never figured out:
How can I bundle up a bunch of changes into a PATCH or DIFF file and either: A) share them with my co-founder; or B) archive them into a standalone change that I can either "apply" or "revert" on my dev box?
At my previous employer, we used an internal tool that let us build so-called DPK files that contained a set of local changes. You could add changed files to the DPK and then share it with colleagues. They could either review the changes in a Diff tool or apply all the changes from the DPK to test your change on their box. After the review was complete, you could then check in these changes. You could also have multiple DPK's applied at the same time (provided you didn't have overlapping changes).
I want to achieve the same thing with Tortoise SVN + Visual SVN in the VS2010 IDE.
My real-world scenario is that I have some extensive change pending but uncompleted on my box. I want to ZIP up these changes and store them in a DIFF file, revert the changes, move on to something else, work on that, and in a few days reapply my changes from the archived DIFF file.
Reluctantly answering my own question. This feature is available with Tortoise SVN. Basically, you make a PATCH file, distribute it or archive it, and then you apply the PATCH. The only trick is to make sure you're in the right location in the WC (Working Copy) when you do the "apply". When you apply, you'll get a popup menu to the left with a list of all files in the changelist. You can apply the patches one by one or in bulk. Seems to work great. I should have drilled into the docs more before posting this question.
Here's the text for picking the location:
"Patch files are applied to your
working copy. This should be done from
the same folder level as was used to
create the patch. If you are not sure
what this is, just look at the first
line of the patch file. For example,
if the first file being worked on was
doc/source/english/chapter1.xml and
the first line in the patch file is
Index: english/chapter1.xml then you
need to apply the patch to the
doc/source/ folder. However, provided
you are in the correct working copy,
if you pick the wrong folder level,
TortoiseSVN will notice and suggest
the correct level."
Be sure to pick the location carefully. If Tortoise SVN can't find it because you selected the wrong node in the VS file explorer, it will try to find a matching location and that might be wrong. In my tests, the Patch feature actually tried to map to a branch (!!) when I specified the wrong location.
Here's the relevant link:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html