Subversion generally works best without locking, using the “Copy-Modify-Merge” methods described earlier in “A solução Copiar-Modificar-Unificar”. However there are a few instances when you may need to implement some form of locking policy.
Você está usando arquivos “não combináveis”, por exemplo, arquivos de imagens. Se duas pessoas mudarem o mesmo arquivo, a combinação não será possível, assim as alterações de alguém serão perdidas.
Sua empresa desde sempre usou um sistema de controle de versão por bloqueio no passado e decidiu que “bloquear é o melhor”.
Firstly you need to ensure that your Subversion server is upgraded to at least version 1.2. Earlier versions do not support locking at all. If you are using file:// access, then of course only your client needs to be updated.
Os três significados de “Bloquear”
Nesta secção, e em particamente em qulaquer parte deste livro, as palavras “bloqueio” e “bloquear” descreverm um mecanismo de mutua exclusão entre utilizadores para evitar colisões ao submeter. Infelizmente, existem outros tipos de “bloqueio”s com que o Subversion, e por consequência este livro, deve ter em conta.
The second is working copy locks, used internally by Subversion to prevent clashes between multiple Subversion clients operating on the same working copy. Usually you get these locks whenever a command like update/commit/... is interrupted due to an error. These locks can be removed by running the cleanup command on the working copy, as described in “Limpar”.
E por terceiro, ficheiros e pastas podem ficar bloqueadas se estiverem a ser usadas por outro processo, por exemplo, se tiveres um documento word aberto no Word, esse ficheiro está bloqueado e não pode ser acedido pelo TortoiseSVN.
Por norma podes descartar esses outros tipos de bloqueios, até acontecer algo errado que requeira o teu apoio
Por padrão, nada é bloqueado e qualquer um que tenha acesso para submissão pode alterar qualquer arquivo a qualquer momento. Outros atualizarão suas cópias de trabalho periodicamente e as mudanças no repositório serão combinadas com as alterações locais.
If you Get a Lock on a file, then only you can commit that file. Commits by all other users will be blocked until you release the lock. A locked file cannot be modified in any way in the repository, so it cannot be deleted or renamed either, except by the lock owner.
Importante
Um bloquei não está associado a um usuário específico, mas para um usuário específico e sua cópia de trabalho. Existindo um bloqueio em uma cópia de trabalho também prevê que o mesmo usuário submete o arquivo bloqueado de outra cópia de trabalho.
As an example, imagine that user Jon has a working copy on his office PC. There he starts working on an image, and therefore acquires a lock on that file. When he leaves his office he's not finished yet with that file, so he doesn't release that lock. Back at home Jon also has a working copy and decides to work a little more on the project. But he can't modify or commit that same image file, because the lock for that file resides in his working copy in the office.
However, other users will not necessarily know that you have taken out a lock. Unless they check the lock status regularly, the first they will know about it is when their commit fails, which in most cases is not very useful. To make it easier to manage locks, there is a new Subversion property svn:needs-lock. When this property is set (to any value) on a file, whenever the file is checked out or updated, the local copy is made read-only unless that working copy holds a lock for the file. This acts as a warning that you should not edit that file unless you have first acquired a lock. Files which are versioned and read-only are marked with a special overlay in TortoiseSVN to indicate that you need to acquire a lock before editing.
Locks are recorded by working copy location as well as by owner. If you have several working copies (at home, at work) then you can only hold a lock in one of those working copies.
If one of your co-workers acquires a lock and then goes on holiday without releasing it, what do you do? Subversion provides a means to force locks. Releasing a lock held by someone else is referred to as Breaking the lock, and forcibly acquiring a lock which someone else already holds is referred to as Stealing the lock. Naturally these are not things you should do lightly if you want to remain friends with your co-workers.
Locks are recorded in the repository, and a lock token is created in your local working copy. If there is a discrepancy, for example if someone else has broken the lock, the local lock token becomes invalid. The repository is always the definitive reference.
Select the file(s) in your working copy for which you want to acquire a lock, then select the command → .
A dialog appears, allowing you to enter a comment, so others can see why you have locked the file. The comment is optional and currently only used with Svnserve based repositories. If (and only if) you need to steal the lock from someone else, check the Steal lock box, then click on .
You can set the project property tsvn:logtemplatelock to provide a message template for users to fill in as the lock message. Refer to “Configurações do Projeto” for instructions on how to set properties.
If you select a folder and then use → the lock dialog will open with every file in every sub-folder selected for locking. If you really want to lock an entire hierarchy, that is the way to do it, but you could become very unpopular with your co-workers if you lock them out of the whole project. Use with care ...
To make sure you don't forget to release a lock you don't need any more, locked files are shown in the commit dialog and selected by default. If you continue with the commit, locks you hold on the selected files are removed, even if the files haven't been modified. If you don't want to release a lock on certain files, you can uncheck them (if they're not modified). If you want to keep a lock on a file you've modified, you have to enable the Keep locks checkbox before you commit your changes.
To release a lock manually, select the file(s) in your working copy for which you want to release the lock, then select the command → There is nothing further to enter so TortoiseSVN will contact the repository and release the locks. You can also use this command on a folder to release all locks recursively.
To see what locks you and others hold, you can use → . Locally held lock tokens show up immediately. To check for locks held by others (and to see if any of your locks are broken or stolen) you need to click on .
A partir deste menu de contexto você pode também obter ou liberar bloqueios, assim como quebrar e roubar os bloqueios mantidos por outros.
Evite a quebra e Roubos de Bloqueios
If you break or steal someone else's lock without telling them, you could potentially cause loss of work. If you are working with unmergeable file types and you steal someone else's lock, once you release the lock they are free to check in their changes and overwrite yours. Subversion doesn't lose data, but you have lost the team-working protection that locking gave you.
As mentioned above, the most effective way to use locking is to set the svn:needs-lock property on files. Refer to “Configurações do Projeto” for instructions on how to set properties. Files with this property set will always be checked out and updated with the read-only flag set unless your working copy holds a lock.
As a reminder, TortoiseSVN uses a special overlay to indicate this.
If you operate a policy where every file has to be locked then you may find it easier to use Subversion's auto-props feature to set the property automatically every time you add new files. Read “Definição automática de propriedade” for further information.
Quando você criar um novo repositório com o Subversion 1.2 ou superior, quatro modelos de gancho são criados no diretório hooks no repositório. Eles são chamados antes e depois de efetuar um bloqueio, e antes e depois de liberar um bloqueio.
It is a good idea to install a post-lock and post-unlock hook script on the server which sends out an email indicating the file which has been locked. With such a script in place, all your users can be notified if someone locks/unlocks a file. You can find an example hook script hooks/post-lock.tmpl in your repository folder.
Você também pode usar ganchos para proibir a quebra ou o roubo de travas, ou talvez limitá-lo a um administrador nomeado. Ou talvez você queira enviar um e-mail para o proprietário quando um de seus bloqueios é quebrado ou roubado.
Leia “Rotinas de eventos no servidor” para saber mais.