RE: Out of date errors
From: David Balažic <David.Balazic_at_comtrade.com>
Date: Tue, 27 Dec 2016 13:47:34 +0100
What you say below is wrong. There is no need for an explicit UPDATE in the scenario of >single user changes files and commits them every now and then<.
If there is a situation when an update is needed, TSVN tell that in clear language and even offers a button, to do an update and then later retry the commit.
I suspect the OP has a different problem.
Regards,
From: Bruce J Clark [mailto:BJClark_at_metrol.co.uk]
Hi,
If I understand your issue correctly, this is more of a Subversion issue than a ToroiseSVN issue.
It is easy to get out of date errors, even for a stand-alone user. Fortunately, It's also easy to avoid.
To get out of date errors, simply checkout a project, make some changes and then commit those changes. At this point the local copy is "out of date" with the repo. The SVN commit process updates that the files that were changed but nothing else is updated in the local checkout. This includes the other checked out files and folders, including folders that contained files from the previous change. The latest repository revision is now higher that the local checkout, for everything except the items that were changed during the commit.
The easiest solution is simply to run the SVN update command after a commit. This uodates the local checkout to match the repository state. Now, as the only user, this is mostly cosmetic since nobody else will have changed the repo and so there will be no other changes to get during the update. However, the key thing is that the .svn folder is updated to confirm that the other files haven't been changed. [In a more typical repository, it's quite possible that other users have changed some of the other files and they'll need to be updated with those changes.]
What happens if you don't do the SVN update? You make further changes to the local copy. When the changes are complete, you run the SVN commit. The first step of the commit is to check that the local checkout is up to date; it isn't, because the repository is at a new revision (based on the earlier commit), compared to the local copy. [Remember, it's not just whether the files are the same, it's whether the local .svn folder has been updated.] At this point SVN, knows that the repsoitory has been updated since the last full checkout/update but it doesn't know what the differences are. SVN simply notes the difference between the repo and the local checkout and reports that the local checkout is out of date. At this point, TortoiseSVN, helpfully offers to run the update first, before retrying the commit. That should work just fine since you're the only repo user and there's nobody else changing the files. That's largely cosmetic since the file contents are already OK, and it's simply updating the .svn folder.
Hope this helps.
Bruce Clark
[Metrol logo]<http://www.metrol.co.uk>
This email and any attachments or links herein are confidential and may contain Metrol Technology Limited proprietary information that is legally privileged or otherwise protected from disclosure. It is solely intended for the person(s) named above. If you are not the intended recipient, any reading, use, disclosure, copying or distribution of all or parts of this email or associated attachments or links to other web locations, is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message or by telephone and delete this email and any attachments or links permanently from your system. Metrol accepts no liability for any damage of whatever nature caused by this email. Registration Number SC105658. Registered in Scotland.
________________________________
Dear Ladies and Gentlemen,
I started using Tortoise/Subversion a few years ago but after trying a previous version of a program and after that being unable to roll back to the latest version (I suspect I should have commited first but the program didn't want for it) and losing my changes I keep commiting from time to time but I am not using it as it was intended. When code I use has to be used by one of my employees (who all work on different locations) we simply send files and hand compare, which is a lot safer.
However, despite my "stand alone" use I regularely get out of date errors. The internet is full of this problem with dozens of different solutions. If always costs me a lot of time to solve it. The way I solved it now is to delete the .svn directory and re-register the project.
My question is: why isn't there a simple option to tell the program: stop complaining about conflicts and just commit the whole project/solution in the current state as the right code? Especially the way I work there could not be any out of date or conflict state except a "conflict" caused by the Subversion/Tortoise (no idea which of the 2 caused the problem). I couldn't find something like that in TortoiseSVN-1.9.5.27581 either. That would at least save a lot of time.
Best regards,
Dick van Kooten
[http://www.ic2.com/images/logoklein.gif]<http://www.ic2.com/>
IJsvogel 16
3362 KC SLIEDRECHT
telephone
(31)-(0)184-420384
internet
www.ic2.com<http://www.ic2.com/>
KvK
23059514
------------------------------------------------ DISCLAIMER ------------------------------------------------
------------------------------------------------ DISCLAIMER ------------------------------------------------
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
|
This is an archived mail posted to the TortoiseSVN Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.