Ok i have a working copy and i want to know its revision
I know about the Subrevision tab in the properties window of the working copy but it doesn't show the last revision i updated the working copy to.. In the working copy not all the files at the same revision
The way i'm working with the working copy is the following :
- i checkout a working copy of the repository.
- then i do some modifications and commit them.
- i continue working on the same working copy.. I don't checkout a new one.
- if there're some requierd updates i do them.. Continue working.. Commiting.
So i never checkout a new working copy as i have one so i always work-update-commit on it.
So sometimes i need to work somewhere else so i copy the working copy folder to another PC where there's no connection with the repository.. I do some work on it.. Take it back to the work PC and commit it.
So sometimes i get confused about the last working copy i committed so i need to check their revisions and work with the higher one.
You can use the SubWCRev tool for this.
Related
I've tried searching for answers to my problem but every thread starts talking about branches and trunks and I have no idea what they're talking about.
I'm in a team of 2. We've started working on a single excel spreadsheet. I use SVN update before making my changes, however while I'm making changes, my team-mate also makes changes and commits them before I do.
I was first told that I simply have to update again before I commit and it should merge my team-mate's changes with mine. However when I update the .xlsx file, nothing seems to happen. I open up my local copy again and it isn't showing my team-mates changes. I've tried using the merge option and clicked random things in numerous attempts but nothing works. Nothing I've tried will add my team-mates changes to my working copy. Every time I compare my working copy with the repository, the changes from both of us are all highlighted, but nothing I do seems to merge them together.
The cells we modify in the spreadsheet are different ones, so we don't both make direct changes to the same cell. It should be a simple merge.
This is driving me up the wall, it keeps saying "merge successful" or "update successful" but it isn't doing anything.
.xlsx files are not text-files (they are really zip-archives), don't expect merging of such files from Subversion in any case
You can't have easy teamwork with Office's documents
First of all, xlsx files are binary rather than textual so SVN cannot merge them very well. So two of you working on one such file at the same time will not work well even if nothing goes wrong.
As for why you never saw the changes, probably you still had the file with your changes open in Excel when you did your update, and Excel never prompted to load the new changes.
To correct the immediate situation you can move your version of the file elsewhere, svn update to get the repository version back, and manually compare and resolve the differences.
In the future, since SVN is not suited well for merging this type of file, set the svn:needs-lock property on this file, and always be sure to svn lock it before editing to keep your coworkers from making changes at the same time.
If you need simultaneous editing capabilities, look into what cloud services Microsoft offers, or switch to Google Docs or similar.
I wanted to transfer my work from on pc to another (at home). I checked in a shelve set on my main pc. I pulled it from my laptop fine. I then updated my code on my main pc and made another shelve set. I pulled it again on my laptop. It was taking some, so I cancelled the operation and deleted the whole directory on my laptop disk. When I tried getting the shelve set again I just get
Multiple error occurred during the operations, the first of which is
displayed below. A full error list is available in the Output Window
You cannot unshelve a change to $/Business/Path/Logic because there is
a conflict on this item in your workspace
The output window lists about 100 of these:
You cannot unshelve a change to $/Business/Path/Logic/app.config because there is
a conflict on this item in your workspace. You must first resolve the conflict or exclude this file when you unshelve the shelveset.
What? I just want a new copy of the latest shelve set. I tried mapping to a new path on my laptop, but same thing.
Thanks
Thomas
Sounds like when you "deleted the whole directory" on your laptop source control actually picked this up as a change. If that is the case your laptop should actually show that you have changes in your "My work" area. If you do and didn't really intend to make that change just undo the checkout.
This version of VS is a little different... even if you make a change using the Explorer and not within the VS source control explorer it can pick that change up. This is normally a great thing... you can use whatever editor you like and it will count that as a change. But you have to be aware that it is going to do that so that you don't accidently make unintended changes.
I have used svn for a while but recently a couple teams were added to the project. One of the teams made a new branch and has asked me to check some of their changes. I went to the directory, right click, svn->switch and chose the new branch. I went in and tried to echo something to the page I was on to see if I was working in the new branch and I wasn't. This is a little beyond what I do but with the project getting so big I need to learn this.
Based on that, my question..is there something more to this that I am not doing? After switching the working copy to this new branch how do I work on it?
The difference between checkout and switch might be adding to the confusion. I think that in your case it would be simpler to just check out the branch to a different folder since you're just doing review and it may be the most straightforward way to proceed regardless.
See this section from the Tortoise docs:
To Checkout or to Switch...
...that is (not really) the question. While a checkout downloads
everything from the desired branch in the repository to your working
directory, TortoiseSVN → Switch... only transfers the changed data to
your working copy. Good for the network load, good for your patience.
:-)
To be able to work with your freshly generated branch or tag you have
several ways to handle it. You can:
TortoiseSVN → Checkout to make a fresh checkout in an empty folder.
You can check out to any location on your local disk and you can
create as many working copies from your repository as you like.
Switch your current working copy to the newly created copy in the
repository. Again select the top level folder of your project and use
TortoiseSVN → Switch... from the context menu.
In the next dialog enter the URL of the branch you just created.
Select the Head Revision radio button and click on OK. Your working
copy is switched to the new branch/tag.
Switch works just like Update in that it never discards your local
changes. Any changes you have made to your working copy which have not
yet been committed will be merged when you do the Switch. If you do
not want this to happen then you must either commit the changes before
switching, or revert your working copy to an already-committed
revision (typically HEAD).
If you want to work on trunk and branch, but don't want the expense of
a fresh checkout, you can use Windows Explorer to make a copy of your
trunk checkout in another folder, then TortoiseSVN → Switch... that
copy to your new branch.
In the regular "Properties" dialogue (right click on Windows explorer) you have a "Subversion" tab that will tell you what URL the file or directory points to. Use that to verify that you actually switched to the correct branch.
It's also worth nothing that any non-committed local changes will still be in your working copy.
There might be a misconception about svn switch :
At first I thought that the existence of a switch command would imply that there were a "current" or a "selected" working copy for the proper functioning of SVN. Like I'm currently working on trunk, then I'm working on a branch B, hence "switching" from a working copy to another. The truth is : there is no such thing as a current working copy ! There are just many local working copies : one for the trunk, one for a branch another for a tag and so on. But none would be "implicitly selected".
As Paul Sasik quotes : switch would allow, for instance, to have only one working copy of say, the trunk, and then, merging that local working copy with a targeted branch or tag from the remote repository. switch only sync differences between local and remote, hence avoiding to do a whole check out of a solution. Past exectution of command, every further commits on the working copy will occur on the distant repository folder which's been switched to, which's been targeted. No matter what the initial check out was for that local folder.
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
I use tortise svn in VS2010. When I go to commit my changes at the end of the day, I get the following error.
Commit item 'folder / filename' has copy flag but an invalid revision.
What does that mean and how do I resolve it? I Googled for it but really only saw a transcript of a rather esoteric discussion for a Java-related issue.
EDIT - 10/25/2010
Nothing? Really?
I agree with Pekka's comment. Right click on the project folder -> TortoiseSVN -> Check for modifications. Take note of the files you changed.
Create a new folder - and checkout the repository to the new folder. Move the files that changed back into the new folder, replacing any existing ones. Try your commit again.
You may try doing this with Windows Explorer instead of Visual Studio.
have you renamed that folder[say, folder1]?
If not then, "export" the content of that folder to somewhere else[say, folder2].
go back to parent of folder1 and delete then update folder1.
replace all the files[*not folder*s] in folder1 with the equivalent files from folder1
now commit folder1 independently after stealing any lock if exists.
What happens if you try to get the latest revision (update before committing, but after you back up your code ;)?
It sounds like there is potentially something that is in conflict in a bad way - you may need to back up your files, update or check out a new working copy, and then replace checked out files with your old ones.
check out a clean copy. put in the changes you previously made. commit.
do that, and try to forget your problems. it should work.