| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Olha.. eu só perdi um na altura do 486 e foi o último, pois a partir desse dia, comecei a fazer backups e agora até a ter outro disco a fazer backup da minha home e de vez em quando ainda gravo para DVD-RW :-)
Characteristic of life style... |
| |
| | Isto lembra-me como seria interessante se o próprio sistema de ficheiros tivesse um sistema de algum modo semelhante ao CVS. Alguma coisa em que fosse possível uma pessoa poderia editar um fechar, fechá-lo, voltar a abrir e ter à disposição todos os "Undos" como se nunca o tivesse fechado...
Já existe algo deste género?
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
| |
| | Pois, mas pelo que sei, o CVS não faz versioning de directorias. Já agora, penso que o Windows 2003 tem uma funcionalidade algo semelhante (file rollback, acho), para obter versões prévias de ficheiros entretanto alterados, funcionando tanto em fs local como em fs de rede.
Why do you Linux and drive when you can BSD and fly? |
| |
|
| | Acho que funciona também nos discos locais desde que acedidos pelo smb redirector: ex: \\127.0.0.1\C$
|
| |
| | | subversion # Directories, renames, and file meta-data are versioned. Lack of these features is one of the most common complaints against CVS. Subversion versions not only file contents and file existence, but also directories, copies, and renames. It also allows arbitrary metadata ("properties") to be versioned along with any file or directory, and provides a mechanism for versioning the `execute' permission flag on files.
|
| |
| | O que eu dizia era mais algo do tipo: escreveste um relatório no OpenOffice, depois fecha-lo, após uns dias abres novamente e puderes efectuar os Undos para as alterações anteriores. Quem diz o OpenOffice, diz um editor de texto ou de imagens.
Algo mais transparente e mais confortável de usar. Algo que fizesse com que o actual método de carregar no botão de Gravar ficasse obsoleto.
Esta ideia não é de minha autoria, foi algo que foi desenvolvido numa discussão no KDE que começou pelo facto do ícone do botão de gravar ser uma disquete (algo muito pouco intuitivo).
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
| | "escreveste um relatório no OpenOffice, depois fecha-lo, após uns dias abres novamente e puderes efectuar os Undos para as alterações anteriores."
Se não me engano, isso é algo ao nível das aplicações. Não necessariamente do sistema de ficheiros.
"ícone do botão de gravar ser uma disquete (algo muito pouco intuitivo)."
De facto, para quem chega hoje ao 'maravilhoso mundo da informática', um ícone com uma disquete não lembra ao diabo! Eu próprio há mais de um ano que não toco numa disquete. No entanto, para mim, o ícone não me confunde. Mais: confundir-me-ia se não fosse uma disquete.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| |
| | Se não me engano, isso é algo ao nível das aplicações.
Sim, teria que haver uma implementação a nível de software, não necessariamente de cada aplicação individual, mas do sistema. De qq maneira, convém que o sistema de ficheiros também tenha suporte para isso de forma a haver uma interoperabilidade entre sistemas. A parte de software deveria só abstrair estas funcionalidades, de forma a puderes trocar, por exemplo, entre KDE e Gnome sem perderes esta funcionalidade.
De facto, para quem chega hoje ao 'maravilhoso mundo da informática' um ícone com uma disquete não lembra ao diabo!
Exactamente.
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
| | Já agora, que é isso na tua assinatura? Se tivesse sido mesmo uma garina a gravar o teu nick no rabo ainda vá lá. Agora uma montagem... Bah. :D
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
| | Não teria piada se não fosse uma montagem. Era preciso ser uma garina muito imbecil para tatuar o nome/nick/whatever dum gajo no rabo. Ainda para mais uma tatuagem tão feia como aquela... Mas pronto, não és obrigado a gostar :)
Why do you Linux and drive when you can BSD and fly? |
| |
| | surpreendias-te...
-----
Windows isn't done until Lotus won't run. |
| |
| | "Já existe algo deste género?"
No sistema operativo Genera (que tem mais de 20 anos), o FS tinha versioning. Não é propriamente rocket science. :-)
|
| |
| | O sistema de ficheiros do OpenVMS suporta algo desse género, mas acho que apenas guarda histórico de ficheiros e não de directorias.
--
Carlos Rodrigues
|
| |
| | Eu referia-me mesmo a algo a nível de ficheiros individuais.
É excelente ver que já existia algo como isto há anos. É triste ver que não existe algo como isto hoje.
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
| | | Sim, o VMS vinha com isso de raiz. Se bem me recordo, o path completo de um ficheiro era "MAQUINA::DEVICE:[.dir1.dir2]file.ext;version". Sempre que "tocavas" em "file.ext" criavas um "file.txt;version+1" (ex: "a.txt;1" "a.txt;2" etc) Mas digo-te sinceramente, isto era tão "annoying" que a primeira coisa que as pessoas faziam era arranjar esquemas de apagar todas as versões excepto a última. Aliás, acho que havia um comando do próprio sistema que fazia isso, o purge.
|
| |
| | Parece-me que isso foi mais um problema de má implementação do que má invenção. Uma forma simples de resolver esse problema seria que quando o último sufixo ";version" estivesse ausente, o sistema assumiria que o utilizador se estava a referir à última modificação.
Também isso não é exactamente a mesma coisa que eu pedia, até porque esse ficaria muito dispendioso visto guardar a cópia integral de todas as modificações e não apenas a informação do que foi alterado.
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
| | Uma questão que se põe é a da segurança. Se alguém que use um sistema desses e volta e meia possua ficheiros com informação sensível, aquando a sua remoção, possuirá sempre no repositório uma versão do ficheiro (a não ser que o apague manualmente), correcto? Alguém que tenha acesso ao repositório pode aceder a documentos que, de outra forma, não existiriam...
Já há uns tempos um caramelo tinha sido notícia por configurar "roaming profiles" via cvs... mas continuo a achar um desperdício de espaço. É, a meu ver (e em caso de grande quantidade de informação) muito mais eficiente criar um script com o rsync de forma a que periodicamente seja feita uma cópia integral do que se deseja salvaguardar, e frequentemente seja feito um backup diferencial. Assim mantém-se um número limitado de versões, e possui-se todo o "histórico" de modificação, sem pôr em causa ficheiros removidos há tempo suficiente para não serem necessários.
Why do you Linux and drive when you can BSD and fly? |
| |
| |
| | | mas continuo a achar um desperdício de espaço. Nem por isso. No caso do subversion são apenas guardados os deltas, mesmo para binários. Num repositório com aprox 450MB de dados reais em ficheiros, e com cerca de 4000 revisões incluindo muiitos binários (sic e contra minha vontade, diga-se), o repositório ocupa pouco mais que 600MB. Um overhead nada pesado em minha opinião.
|
| |
| | | este é um método interessante de, para além de manter backups Atenção, nada de misturar conceitos. Usar o CVS ou subversion (etc) não é uma forma de fazer backup. Cingindo-nos a esta vertente apenas, essas ferramentas substituem um dump ou tar diferencial. Um backup consiste em deslocar dados (diferencialmente ou não) para outro suporte. Para um sistema de source control (de repositório central) funcionar como alternativa a backup, o repositório em si tem que continuar a ser backed-up pelos meios tradicionais.
|
| |
| | Fogo, de repente assustei-me... Li qualquer coisa do género "A tua vida num SUPOSITÓRIO".
Por acaso este artigo vem a calhar, pois já ando há 15 dias a experimentar o Subversion (Linux (SVN), Windows(Tortoise) e VS.NET(Ankh)) e estou impressionado. O único problema que vejo é o já mencionado num Post acima: E os backups do Repositório?
----
//\anuel /|zevedo |
| |
| |
| | Podes sempre ter o repositório backed-up integralmente e zipado. Como só tens um ponto central os dados todos é fácil ter um cron.d+tar ou whatever para fazer isto. E de vez em quando faz-se um DVD com isso. O que o SVN resolve é a integridade dos dados distribuídos e o histórico. Se o repositório for à vida ficas sem nada (se bem que tens sempre as cópias locais nos vários check-outs, mas perdes nesse caso o histórico).
BTW, subversion rulez :). Tenho na empresa um repositório enorme (79.000 ficheiros,6 GB de checkout) com binários à mistura e funciona 5 estrelas com http+webdav. Falta só uma feature opcional de locking para aqueles 10 casos por ano em que, de facto, fazia jeito!!!
Tó-Zé 'Senador' |
| |
| | Para backups eu prefiro não tocar no repositório per se, mas antes usar o svnadmin dump para lhe retirar o sumo. Algo do estilo "svnadmin dump path-to-rep | gzip -1 > rep-bak.svn.gz", com o mesmo user owner de "path-to-rep" (importante!).
O dump tem a opção --incremental que sinceramente não usei, mas rapidamente vou ter que a considerar, caso contrário o fulldump começa a demorar demasiado tempo, e desta forma até é mais fácil desenhar um esquema qualquer mais leve de redundância de backups.
|
| |
| | Para backup nunca tive problemo. Claro que um dump é melhor, mas é muito lento porque faz replay da história toda. Usei só o dump quando tive de mudar de versão de svn (de 1.0.x para 1.1.x) e funciona muito bem.
Tó-Zé 'Senador' |
| |
| | Nao esquecer q o svn faz diffs binarios. o que torna bastante reduzido o espaco necessario para o repositorio. MAs devido a' estrutura do proprio svn no lado do cliente este tamanho chega a ser o dobro necessario.
subversion e' bastante bom mesmo para ambientes windows based. Especialmente para projectos .NET. O unico prob e' fazer checkouts de webprojects. Pra isso existe uma versao modificada do Tortoise q da bastante jeito. Nao percebo porque nao a suportam, uma vez ser necessario incentivar o uso do svn no windows. E nao percebo pq raio nao dao a possibilidade de alterar o tipo de dir criado, se' tudo uma questao do lado do cliente sem influencia pro repos.
O problema esta no VS.NET e nao propriamente do windows, do subversion ou do tortoise. Segundo sei o VS.NET 2005 ja corrigiu este bug. Resta esperar.
Outro ponto onde ainda acho ser necessario investir algum tempo e' num gui para macosx decente.
Existe um mas nao ta completo a nivel de autenticacao, e ou integracao com ferramentas geralmente usadas nesse ambiente. Dreamweaver flashes photshops corels etc.
Ainda ha de chegar o dia em q conseguirei meter os webdesigeners e os flash coders a fazer commits sem hassles ou nao usar a palhacada que sao todos os clientes de ftp para MAC de forma rapida e simple s com 1 click do mouse, e adicionarem a sua propria contribuicao em forma de comment. Que abrir attachaments e respectiva explicacao em emails.
Qt aos backups, solucao mais pratica, barata(custo MB/¤) e mais simples e' um DVDRW...
Por agora acaba por ser enviar dumps do repos pra maquinas fisicamente afastadas e esperar q nao aconteca nada.... o que e' lamentar.
MAs estou bastante satisfeito com a solucao adoptada. E recomendo vivamente a quem trabalhe com 1 ou mais pessoas ;)
Mesmo pra projs locais, o tempo perdido a setupar um repos, importar, commit, checkouts compensa bastante.
Socrates, ja tou a sentir o prometido choque tecnologico ou isto e' o meu telele em modo vibrador? |
| |
|
