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
lesmikesell_at_gmail.com
Received on 2011-07-26 17:10:33 CEST