SVN Functionality: loss of locks when switching to a branch
From: REYNOLDS, Dylan <DYLAN.REYNOLDS_at_airbus.com>
Date: Fri, 3 Sep 2010 11:38:57 +0200
My SVN versions - apologies if anything I write is out of date:
I am currently working on a project with file that cannot be merged and hence require the use of locks and svn:needs-lock.
Even though we want to use locks we still also want to use branching. This allows us to still have a buildable trunk, it keeps the logs of branch work and trunk work separate and it promotes good branch working practise for other projects where merging may be possible.
The ideal would be that the team could lock the trunk down while they work on their branch. Then some other colleague could check out the trunk to build with but not edit the trunk.
Here is the problem:
If you have the trunk as your working copy.
Now as desired the trunk is locked. If all files have svn-needs-lock then everything is as you wanted it to be.
However, now you have finished with the branch and you want to merge it to trunk.
The solution is then to steal the lock back from yourself. This doesn't seem right. Particularly not to tell the team that in their normal working practise they have to steal their locks back.
In my opinion, if the lock exists in the repository, under your user name, then why can't this information be pushed in to your working copy when you make the update/switch/checkout?
A check should be performed for repository locks that belong to the username checking out (or switching) that working copy. If the usernames match then you should get your lock, along with the files.
I understand that locking is an "extra" functionality of svn. However, it can be very useful for some files and it seems under supported in svn.
It would be even more useful if locks and the lock holder were pushed out to every user when they updated/checked out their working copy. This would resolve the above issue and also mean that all updated working copies would show that the file is locked by you or locked by someone else.
Kind Regards,
Dylan Reynolds
________________________________________
This e-mail and any attachment may contain confidential and/or privileged information. If you have received this e-mail and/or attachment in error, please notify the sender immediately and delete the e-mail and any attachment from your system. If you are not the intended recipient you must not copy, distribute, disclose or use the contents of the e-mail or any attachment.
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.