On 7/26/2011 7:48 AM, Andy Canfield wrote:
As I understand Subversion, [a] The server has no idea who has a working copy. [b] The checkout builds a working copy on the workstation from the server's repository. [c] What is on the developers hard disk is a working copy. [d] What is on the developer's hard disk continues to be a working copy, even after a commit.
Yes, but it is then a mixed rev and needs an update. That is, the changes you committed belong to the rev the commit creates while the unchanged files belong to the rev of the prior update or checkout.
[e] If the developer tries to make revisions to his working copy six months after his last commit, then tries to commit, he's going to have a major mess on his hands trying to reconcile things. The working copy is still a valid working copy.
Normally you would do an update to pick up and reconcile other changes, then commit.
[f] Unlike a lock, which he grabs and then releases, he never gives up his working copy; it is valid perpetually.
But, in the context of backups, note that you can only commit to the repository where the checkout originated (determined by uuid) and the revision of the repo can't go backwards. So, if you restore a backup older than the rev of your working copy's checkout or last update you won't be able to commit the changes from that working copy. The only reasonable approach to doing that would be to check out the closest match from what is currently in the restored repo, copy over your changed files, and then commit. This could be cumbersome with a large tree with many changes.
-- Les Mikesell lesmikes...@gmail.com
