Afaste temporariamente as alterações não confirmadas no Subversion (à la "git-stash")

Ao programar o software armazenado em um repositório do Subversion, geralmente modifico alguns arquivos, depois percebo que gostaria de fazer algumas alterações preparatórias para o meu trabalho principal. Por exemplo, ao implementar novas funcionalidades, noto alguma refatoração que pode me ajudar.

Para não misturar duas alterações não relacionadas, nesses casos, eu gostaria de "ocultar" minhas alterações, ou seja, reverter para a versão do repositório, fazer outras alterações, confirmar essas alterações e "recuperar" minhas alterações.

O git-stash permite fazer exatamente isso. Existe alguma maneira de fazer isso com o Subversion, diretamente ou com algum plugin ou script. Os plugins do Eclipse também ficariam bem.

Quando tenho alterações não confirmadas de uma tarefa na minha cópia de trabalho e preciso mudar para outra tarefa, faço uma de duas coisas:

1. Confira uma nova cópia de trabalho para a segunda tarefa.

   ou

2. Inicie uma filial:

   workingcopy$ svn copy CURRENT_URL_OF_WORKING_COPY SOME_BRANCH
   workingcopy$ svn switch SOME_BRANCH
   workingcopy$ svn commit -m "work in progress"
   workingcoyp$ svn switch WHATEVER_I_WAS_WORKING_ON_BEFORE
   

Eu tenho alguns scripts que ajudam a automatizar isso.

Esta postagem do blog aconselha o uso de diff e patch.

• git stash torna-se aproximadamente svn diff > patch_name.patch; svn revert -R .
• git stash apply torna-se patch -p0 < patch_name.patch

Observe que isso não esconde alterações de metadados ou (eu acho) o diretório cria / exclui. (Sim, o svn rastreia aqueles separadamente do conteúdo do diretório, ao contrário do git.)

Você pode armazenar suas alterações atuais svn diffem um arquivo de correção e reverter sua cópia de trabalho:

svn diff > stash.patch
svn revert -R .

Depois de implementar seu recurso preparatório, você poderá aplicar seu patch com o utilitário de patch:

patch < stash.patch

Como outros observaram, isso não funcionará com svn:propertiesoperações em árvore (adicione, remova, renomeie arquivos e diretórios).

Arquivos binários também podem causar problemas, não sei como o patch (ou o TortoiseSVN, neste caso, os trata).

A maneira mais fácil seria usar uma ramificação temporária, assim:

$ svn copy ^/trunk ^/branches/tempbranch
$ svn switch ^/branches/tempbranch
$ svn commit -m "Stashed"
$ svn switch ^/trunk
$ ... hack away in trunk ...
$ svn commit -m "..."
$ svn merge ^/branches/tempbranch .
$ svn rm ^/branches/tempbranch
$ ... continue hacking

Isso poderia (e provavelmente deveria) ser colocado em um script se feito com mais regularidade.

A partir de 1.10.0 (13-04-2018), você tem um svn shelvecomando experimental . (O TortoiseSVN suporta o comando ) Não é senão um auxiliar salvar um patch e aplicar novamente, por isso possui as mesmas limitações do svn diff+ patch(ou seja, não pode lidar com arquivos binários e renomear). ( Edit : Parece que o suporte binário está chegando na próxima versão 1.11.0 )

Editar ^ 2: com 1.11.0 (lançado em 30-10-2018), os arquivos binários são suportados . Arquivar arquivos renomeados permaneceu sem suporte. As prateleiras no 1.11 são incompatíveis com as prateleiras criadas pelo 1.10.

Editar ^ 3: com 1.12.0 (lançado em 24/04/2019), a cópia e a renomeação são suportadas . As prateleiras na versão 1.12 são incompatíveis com as prateleiras criadas por versões anteriores.

Editar ^ 4: Não há alterações em relação às prateleiras com 1.13.0 e 1.14.0 . Os comandos ainda estão marcados como experimentais e você precisa definir SVN_EXPERIMENTAL_COMMANDS=shelf3para ativar o recurso. Parece que o recurso não tem triagem no momento .

As notas de design podem ser encontradas no Wiki dos desenvolvedores .

$ svn x-shelve --help
x-shelve: Move local changes onto a shelf.
usage: x-shelve [--keep-local] SHELF [PATH...]

  Save the local changes in the given PATHs to a new or existing SHELF.
  Revert those changes from the WC unless '--keep-local' is given.
  The shelf's log message can be set with -m, -F, etc.

  'svn shelve --keep-local' is the same as 'svn shelf-save'.

  The kinds of change you can shelve are committable changes to files and
  properties, except the following kinds which are not yet supported:
     * copies and moves
     * mkdir and rmdir
  Uncommittable states such as conflicts, unversioned and missing cannot
  be shelved.

  To bring back shelved changes, use 'svn unshelve SHELF'.

  Shelves are currently stored under <WC>/.svn/experimental/shelves/ .
  (In Subversion 1.10, shelves were stored under <WC>/.svn/shelves/ as
  patch files. To recover a shelf created by 1.10, either use a 1.10
  client to find and unshelve it, or find the patch file and use any
  1.10 or later 'svn patch' to apply it.)

  The shelving feature is EXPERIMENTAL. This command is likely to change
  in the next release, and there is no promise of backward compatibility.

Valid options:
  -q [--quiet]             : print nothing, or only summary information
  --dry-run                : try operation but make no changes
  --keep-local             : keep path in working copy

(...)

$ svn x-unshelve --help
x-unshelve: Copy shelved changes back into the WC.
usage: x-unshelve [--drop] [SHELF [VERSION]]

  Apply the changes stored in SHELF to the working copy.
  SHELF defaults to the newest shelf.

  Apply the newest version of the shelf, by default. If VERSION is
  specified, apply that version and discard all versions newer than that.
  In any case, retain the unshelved version and versions older than that
  (unless --drop is specified).

  With --drop, delete the entire shelf (like 'svn shelf-drop') after
  successfully unshelving with no conflicts.

  The working files involved should be in a clean, unmodified state
  before using this command. To roll back to an older version of the
  shelf, first ensure any current working changes are removed, such as
  by shelving or reverting them, and then unshelve the desired version.

  Unshelve normally refuses to apply any changes if any path involved is
  already modified (or has any other abnormal status) in the WC. With
  --force, it does not check and may error out and/or produce partial or
  unexpected results.

  The shelving feature is EXPERIMENTAL. This command is likely to change
  in the next release, and there is no promise of backward compatibility.

Valid options:
  --drop                   : drop shelf after successful unshelve
(...)

$ svn help | grep x-
 x-shelf-diff
 x-shelf-drop
 x-shelf-list (x-shelves)
 x-shelf-list-by-paths
 x-shelf-log
 x-shelf-save
 x-shelve
 x-unshelve

Eu não sei de uma maneira fácil de fazer isso com apenas svn. Honestamente, eu aconselho usar git-svnpara criar um repositório git que funcione como uma cópia de trabalho svn, e apenas usá git stash-lo. Basta substituir git pullpor git svn rebasee git pushcom git svn dcommite você poderá manter 90% do seu fluxo de trabalho git e ainda estar conversando com um servidor svn.

Há um pequeno script Python 2 chamado svn-stashdisponível na GPL 3: https://github.com/frankcortes/svn-stash .

Funciona como as svn diff/patchsoluções mencionadas e oferece o envio e a liberação de alterações conforme as diferenças em algum diretório local. Infelizmente, os stashes não podem ser nomeados e apenas o último pode ser exibido (bem, sim, é uma pilha, mas não há motivo real para essa limitação.) Mas, então, você sempre pode criar os recursos ausentes no fonte.

Ele foi escrito para * ix, mas depois de substituir todos os "/" por os.sepele também funciona bem no Windows.

Se você usa o svn 1.7 ou superior, é necessário alterar is_a_current_stash(): remova a linha if ".svn" in os.listdir(CURRENT_DIR):, pois existe apenas um subdiretório .svn de nível superior nos 1.7 WCs.

Você pode fazer isso facilmente usando o Intellij IDEA - Shelve Changes

outra opção é copiar seu checkout atual para um novo diretório e reverter todas as suas alterações. Dessa maneira, você evitará o incômodo de criar uma ramificação temporária no servidor - afinal, o armazenamento em cache é uma operação local, que nem todo mundo deve ver e pode ser feito com bastante frequência.

depois de confirmar seu hotfix, você pode atualizar sua cópia principal de trabalho e excluir sua "área de armazenamento"

Eu também queria esse recurso. Atualmente, uso o TortoiseSVN.

Eu não encontrei uma solução mais rígida, exceto para exportar a árvore, reverter novamente para o repositório, fazer minhas alterações e confirmar e comparar as alterações da árvore exportada para o meu diretório controlado de origem usando uma ferramenta como Beyond Compare.

Ou, outra solução pode ser ramificar do HEAD para outro diretório, fazer suas alterações e confirmar. Quando estiver pronto para mesclar esses itens à sua outra cópia de trabalho, faça uma atualização e mescle suas alterações.

Eu sempre mantenho um segundo checkout, que chamo de "trunk_clean". Sempre que eu preciso fazer uma alteração rápida e isolada relacionada ao que estou fazendo, eu apenas faço o checkout.

As idéias de ramificação e correção acima são ótimas, mas elas não funcionam bem para mim. Eu uso uma ferramenta visual diff, portanto, a execução git diffnão produz patches baseados em texto. Nosso sistema de criação cria um novo ambiente toda vez que uma ramificação é criada, portanto, a criação de ramificações temporárias "stash" seria uma bagunça.

Em vez disso, escrevi um pequeno script de shell que copia um arquivo para um diretório "shelf", adiciona um carimbo de data e hora e reverte a alteração. Não é tão robusto quanto as soluções acima, mas também evita algumas das armadilhas que encontrei.

Com base na resposta de Walter, criei os seguintes aliases no meu arquivo bashrc:

alias svn.stash='read -p "saving local changes in raq.patch. Existing stash in raq.patch will be overwritten. Continue?[y/N]" && [[ $REPLY =~ ^[yY] ]] && rm -f raq.patch && svn diff > raq.patch && svn revert -R .'
alias svn.stash.apply='patch -p0 < raq.patch; rm -f raq.patch'

Esses aliases são muito mais fáceis de usar e lembrar.

Uso:

svn.stash para esconder alterações e svn.stash.apply para aplicar stash.

Na minha prática, eu uso git initpara criar um repositório Git no trunkdiretório do meu repositório Subversion, e depois adiciono *.gitaos padrões de ignição do Suctions.

Após modificar alguns arquivos, se eu quiser continuar meu trabalho com a linha principal do Subversion, apenas o uso git stashpara esconder meu trabalho. Após me comprometer com o repositório Subversion, eu uso git stash poppara restaurar minhas modificações.

Usar:

svn cp --parents . ^/trash-stash/my-stash

Ele criará uma ramificação a partir do local atual e da revisão atual e, em seguida, confirmará as alterações na cópia de trabalho para essa ramificação sem mudar para ela.

uso: copiar SRC [@REV] ... DST

SRC e DST podem ser um caminho ou URL da cópia de trabalho (WC):

WC  -> URL:  immediately commit a copy of WC to URL

Observe que as alterações na cópia de trabalho não serão revertidas automaticamente ( cpapenas copiando as alterações para uma nova ramificação) e você precisará revertê-las manualmente.

Para restaurar as alterações, basta mesclar as alterações da ramificação recém-criada à sua cópia de trabalho.

svn merge --ignore-ancestry ^/trash-stash/my-stash -c <commited revision>

--ignore-ancestry é usado para não atualizar as informações de mesclagem na cópia de trabalho.

Usar:

svn ls -v ^/trash-stash/

para ver o que você tem no caminho do esconderijo. Revisões confirmadas também são impressas.

Se você não precisar mais do stash, basta executar:

svn rm ^/trash-stash/my-stash

Essa solução é melhor do que usar o patch, pois se novas alterações na cópia de trabalho ou na ramificação atual entrarem em conflito com as alterações no stash, você poderá resolver os conflitos usando o svn significa, enquanto patchem alguns casos apenas falhará ou até aplicará o patch incorretamente.

Como o Subversion não suporta stashrecursos perfeitamente,
eu apenas faço da maneira manual assim.

Coloque Developmente Production(release)projete em um caminho separado.

source\code\MyApp         -- Development
release\MyApp(release)    -- Production(release)

Você pode trabalhar com todos os novos recursos do seu projeto no caminho de desenvolvimento
e só comprometeria um progresso significativo ou algo deveria ser liberado para o estábulo.

Quando você tiver que liberá-lo para produção, abra o projeto de produção, atualize o svn e faça coisas para liberar (compilar, exportar ... etc).

Sei que isso torna um pouco problemático, mas liberar progresso não acontece com frequência (não acontece para mim, mas eu sei que alguns projetos) se comparam para desenvolver progresso, dessa forma se encaixa para mim.

Estou usando o svn para projetos específicos, já que os membros da equipe do projeto o usam, então tenho que segui-lo.
A melhor solução é usar gitum sistema de controle de versão perfeito e melhor que svn.