Controle de versão contínua

Question

Eu não vi um sistema contínuo de controle de versão - um que salvaria alterações no seu código à medida que você as desenvolveu, em vez de esperar por um check -in oficial. As mudanças seriam salvas como 'não verificadas', é claro, mas elas iriam Seja salvo para o backup e a visualização por outras pessoas antes de você realmente fazer o check -in oficial.

Eu não vi isso, e me pergunto se, ou algo parecido, existe, e as razões pelas quais pode ou não ser uma boa ideia.

No momento, os programadores pensam no controle do código -fonte como integrando pacotes de código, mas por que não tornar esses pacotes menores e se integrar continuamente?

-Adão

Answer 1

No momento, os programadores pensam no controle do código -fonte como integrando pacotes de código, mas por que não tornar esses pacotes menores e se integrar continuamente?

Eu diria que os DVCs já estão basicamente fazendo isso agora, não porque são descentralizados, mas porque cometer é muito mais rápido ... com o git eu comprometo com muito mais frequência do que com o SVN .. também simplifica "pedaços" ou específicos de código (usando git add -i ou git gui), e geralmente é muito mais focado em rastrear linhas de código, em vez de arquivos completos (como subversão "tradicionais" VCs)

Além disso, a maneira como o git funciona inerentemente significa, como você disse: "As mudanças seriam salvas como 'não verificadas', é claro" .. Quando você se compromete, as mudanças são locais, então você as empurra para a máquina remota com uma separada comando .. você pode se comprometer toda vez que economizar e rebaixá -los em um único compromisso, se desejar.

Quanto a uma ferramenta que faz "controle contínuo da versão", você pode fazer isso simplesmente com um script de shell, algo como ..

while [ 1 ]; do
   git add -a && git commit -m "Autocommit at $(date)";
   sleep 10;
done

Há um script, CACM (Github), que faz algo semelhante

CACM] assiste a um diretório específico e comete todas as alterações em um repositório GIT independente.

Para usar apenas fazer:

cacm --repo dir_of_git_repo --watch dir_to_watch

Não sei por que você gostaria de fazê -lo. Acho que uma das coisas mais úteis sobre o uso de um VCS é o diferencial do que mudei (desde a última confirmação). Parece que ter compromissos constantes/automatizados seria apenas barulho.

Também o Editor de texto "E" Tem uma característica interessante, visualiza a história de desfazer, com ramificação. Existe um blog-post nele com capturas de tela.

Answer 2

O trabalho de economia automática constante não é uma tarefa para um sistema de versão, mas para o editor. Quando você vê uma nova versão no sistema de versões, ela deve representar uma mudança significativa das outras versões, nem todas as palavras semi -tenhas.

Answer 3

O Eclipse tem um recurso chamado 'História local' que faz exatamente isso. Ele manterá uma cópia dos seus arquivos de origem entre salvamentos. Ele ainda mantém o controle de pastas excluídas para você. Ele salvou minha bunda várias vezes. Você pode ver a história local como controle de versão de baixo nível que só acontece na sua máquina local. Obviamente, isso é que você trabalha em uma máquina diferente, você terá uma história local diferente.

Answer 4

Você pode usar um sistema de controle de versão de distribuição, como bazar, git, Mercurial. Então você pode se comprometer localmente.

Answer 5

Eu já vi alguns plugins baseados em inotificar para vários DVCs, no entanto, esses podem ser apenas tão inteligentes. Realmente, a coisa ideal a fazer é armazenar o repositório em um sistema de arquivos de cópia sobre gravação, para que essas versões granulares (e imutáveis) frequentes dos arquivos sejam mantidas fora dos DVCs.

Como outros disseram, prefiro assumir muitos pequenos compromissos. Com um DVCS, você não precisa se preocupar em quebrar o porta -malas ou a filial principal, pressionar somente depois de terminar. Não se preocupe com revisões tóxicas ao editar arquivos.

No Linux, eu uso ext3cow Para armazenar meus repositórios HG/Git. Isso me dá o tipo de funcionalidade que você descreve. É triste dizer que não sei nada assim que é portátil além do Linux. Talvez algum time louco crie um em Python.

Essa pergunta surgiu várias vezes antes (embora cada uma delas em um contexto diferente), então certamente a necessidade de algo como ext3cow (mas portátil) é óbvio. No entanto, eu não gostaria desse inchaço em um DVCS, especialmente em árvores enormes.

Eu acho que você realmente precisa pedir isso no sistema de arquivos, não nos DVCs.

Answer 6

Você não quer fazer o check -in todo mudança. Você deseja verificar conjuntos atômicos de alterações que podem funcionar juntas. Você não deseja adicionar um parâmetro a um método e salvar, fazendo o check -in (e uma execução de compilação do CI) e depois a interrupção da construção porque ainda não atualizou as chamadas para o método.

Answer 7

Você quer dizer algo como Autoversão de subversão?

Isenção de responsabilidade: não estou dizendo que a autoversão é uma boa idéia para o desenvolvimento, ou que eu faria pessoalmente, mas a tecnologia existe.

Answer 8

You could commit every line, or character with a DVCS like git if you wanted. Generally, I think it is a great idea to commit as often as possible, when using a DVCS, to make it easy to hunt down problems with tools like git bisect. If you wanted the effect you describe, you could script your editor of choice to commit on every save... In practice though I would think that would be a bit much.

Answer 9

Some people would setup a development branch for this purpose and have the developers commit their changes as they work before merging it into a quality assurance level branch. You could even have a developer doing major changes work in his/her own branch before committing and merging those changes into the main development branch. So, branching can address this.

Answer 10

I think Eclipse does, or used to do something like this at every save. It's saved me a few times when my code ended up being hacked to pieces while trying to identify a bug.

Answer 11

Here is a different approach. Almost every day I run in to situations where something stops working and I don't know why. I rewind a couple of minutes and check what changes have been made and to which files. So I agree on the need for continouos version control.

At the same time it is true that you don't want to checkin thousands of small changes every day into your repository.

Ok, so this is what you do. You use both but don't mix them. Your source control should be used by the whole team and you check in to that every now and then. At the same time you run some local personal file version software that saves every small change and makes it easy for you to actually use the information.

That's it. I use History Explorer since I helped develop it, but there are others out there also.

Answer 12

You might be interested in continuous version control system developed by JetBrains. It's not public yet, but I show some features of it in my keynote at JetBrainsDay in Malmo: http://new.livestream.com/jetbrains/jetbrainsday1/videos/29348962

Answer 13

As Dan mentioned, the IBM Visual Age IDE kept every version you saved of a source code file. This approach isn't limited to IDEs, however; the DEC VMS operating system took a similar approach with its versioned file system. In VMS, the full name of each file included a version number, and each time you saved a file, a new copy was created with a version number one higher than the previously highest number.

Neither approach quite matches version control as we know it today, in that both lack branching (or, for that matter, any features designed especially to facilitate multiple people working on the same source file). But, they both serve the purpose of backup against human error, which for me is the most useful aspect of version control.

Answer 14

Having more than few years of experience of programming in Java, I still remember (with nostalgia) novel approach that Visual Age brought to the development process. Visual Age had a non-file approach to source code. Code was stored in relational database. You’d generally work on a view showing a single method. You also had a full file view, but you wouldn’t use it that much.

Regarding version control, it would generate a version with each save. You could explicitly checkpoint a method, class/interface, package or entire project with a version number/name. It also permitted a more fine grained control of your source on method level. Once I started working with Eclipse, while it inherited many features from Visual Age, and today has History feature that saves locally all “saves” of your code, I couldn’t help feeling I made a step back.

Answer 15

Rational ClearCase has the concept of a dynamic view. On windows, your development view shows as a mapped drive, but your code changes are stored server side as soon as you hit save. Is that what you are looking for?

There are, as you'd expect, trade offs with working this way, so like Si's answer above, this is not a recommendation...

Answer 16

How about VESTA?

http://www.vestasys.org/