I did change one of my code in my php file. I committed those changes using SVN.
Then after discussion with my lead, i reverted those changes and made new changes in same file on local.
Then i took svn update.
I thought it will give previous changes in my local file, but it didn't.
I thought file get merged,but it didn't happened in same way.
How it exactly works let me know?
Related
I have a situation where my depot is saying it has the latest version of a bunch of different files but my local workspace actually has newer revisions. My tools (P4V and VS plugin) are incorrectly telling me that everything is up-to-date.
I can prove this is the case because if I check out the file, make no changes, and submit, the changes are committed and the history appears correct and get latest operations on other machines pull the correct version of the file.
This isn't really a viable solution as there could be many files that require this fix and I have no way of knowing I have fixed them all.
I believe the issue has come about due to occasionally working offline and (incorrectly) twiddling the read only flag on the file when I needed to make a change.
So my question:
Is there a command (or similar) I can run that will look at my workspace files and see that there is a change that hasn't been committed. Essentially ignoring the 'reported' state of the file? Something like sync but in reverse? This would allow me to 'force commit' all those files and get the depot in the correct state.
The command you are looking for is called 'p4 reconcile'. Here's some background information: Working Disconnected from the Perforce Server.
So, I created a new file and copied it over the one in the workspace. Then I selected "reconcile offline work" from the context menu of the directory containing the file, after I've updated the directory and made sure the workspace has the new version of the file - but Perforce says that no files have changed.
There is one more weirdness in this: Despite having the latest version of the program, both the p4 and p4v clients, perhaps, because of the server version, I don't have reconcile command available (I don't know what version is the server, and don't know how to find it out).
So, it would help if you could tell how to do the same thing as reconcile, while not having this command (it seems to be a newish addition, but I cannot imagine a workflow that doesn't require you to use it, or something that does the same thing). The VCS is practically useless if it cannot figure out on its own what files had changed since the last version...
If your server is older, and doesn't support reconcile, there are other ways to accomplish these tasks. Start here for all the details: http://answers.perforce.com/articles/KB_Article/Working-Disconnected-From-The-Perforce-Server
If you added a file to Perforce and copied it to another workspace you will need "p4 sync -k //depot/path/to/file" to reflect the change.
I've been using TortoiseSVN for a while and recently came back to recommitting all my changes and came across an error I've been so-far unable to solve. The only thing about my working folder C:\Development\myproject is that I've added a lot of folders/files since my last commit. What's the best course of action? Also I started an update, however that overwrote some my files, before I paniced and stop it before too much damage was done.
Try using the Clean Up command on the directory, then Update and finally Commit.
If that doesn't work, the error is moaning about deleting a directory with child items. If you know which the folder is, you can delete it by opening it in Repro Browser and delete it through that. After that, Update and Commit again and hopefully it should work. That always solves this error for me.
In linux, how do I check if someone has not yet committed something?
I remember I made changes on a server once..but forgot to commit. Now, I don't know which server I used to make those changes.
It isn't possible to tell if someone else has uncommitted changes in their working copy, because the status of the working copy of each user isn't sent to the repository.
SVN servers/repositories don't keep track of changes made on clients. You'd need to locate all the possible places where the client changes might be and check for modifications there.
This is one of the tradeoffs of not having the server keep track of everything like Perforce does. On the other hand, having the server keep track of everything can be a pain at times.
A local working copy is just that, local. The Subversion repository can't know which client has uncommitted changes.
FWIW, you can check a local working copy status using svn st
svn help st
There is no way to tell if anyone other than yourself has checked out a revision and made changes which have not been committed. The only way to find out is to login as each user and execute svn status in the appropriate directory.
I cannot figure out why I get this error during check-in. I checked in successful only a few hours ago so not sure why now it's complaining
Error: Commit failed (details follow):
Error: Checksum mismatch for
Error: 'C:\sss\sss\trunk\xxxx\.svn\text-base\Header.ascx.svn-base'; expected:
Error: '3cee96f580409a1711a47541a07860dd', actual: 'a5fc0f8819b88bf32ab38d4c9a6b0654'
Error: Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout.
I got latest and also performed a clean-up which said successful so not sure what else to do.
Something has gotten out of sync or has become corrupt, and because it's in your .svn BASE directory, unless you are confident tinkering with this, you're probably better off deleting the parent of the .svn directory and then perform an update. Of course, take a backup or see if an export works before doing this, so you don't lose any changes.
FWIW, I get this sometimes with our library references where Visual Studio seems to keep a lock on some files (even though it's not compiling) and won't let me update them. I believe this is related to the xml documentation files.
Note: Subversion 1.7+ implements a new working copy approach which centralises the meta data, and it now has a single .svn directory at the root of your working copy. Your best bet is a cleanup, failing that a fresh checkout into another directory and export or file copy the corrupted working copy except for the .svn directory, over to the fresh checkout, and commit any local changes.
Looks like one of your SVN files is corrupt. First, check-in everything that can safely be checked in, and make sure to backup everything. Then fix the offending file - usually this involves deleting it from your repository. This should be okay if you're checking in a new version anyway.
I received a similar error after our project repository was moved to a new server. Try reverting your file and reapplying your changes.
I had same problem after googling for some help found articles that suggested to override the checksum in the .svn\entries file. But in that file the checksum was actually as the the expected one in the error message.
To fix the problem, I navigated to .svn\text-base dir of problem file's directory and found out that there's a copy of the file i was trying to check in changes for. I opened that file in Notepad++ and replaced it's content with content of the file to be commited and i was able to commit afterwards.
But just in case, make a backup copy of the .svn\text-base file.
I think this happened because i did an svn update before commit because it complained that my version is outdated. Anyway, it's fixed for me and hope my solution helps someone else too.
With Tortoise SVN, I choose to delete the file in Repo Browser.
First back up the problem file. and use Repo Browser delete the problem file in it, then update local folder so the file in local folder is deleted. Then copy back the backup file and Add > Commit, then I can update successfully.
The disadvantage of this method is the history of this file will be removed.
Also see another post.