O CVS, que é mais usado para gerenciar versões de origem de programas, oferece a possibilidade de manter cópias dos arquivos em vários computadores. Dessa forma, ele também é adequado para sincronização de dados. O CVS mantém um repositório central no servidor, no qual os arquivos e as mudanças feitas neles são gravados. As mudanças realizadas localmente são enviadas para o repositório e podem ser recuperadas de outros computadores por meio de uma atualização. Todos os procedimentos devem ser iniciados pelo usuário.

O CVS é muito suscetível a erros quando ocorrem mudanças em vários computadores. As mudanças são fundidas e, se ocorrerem nas mesmas linhas, um conflito será reportado. Quando ocorre um conflito, o banco de dados permanece em estado consistente. O conflito só fica visível para resolução no host cliente.

Quando o controle de versão não é necessário, mas grandes estruturas de diretório precisam ser sincronizadas em conexões de rede lentas, a ferramenta rsync oferece mecanismos avançados para a transmissão apenas de mudanças entre arquivos. Isso não diz se aplica apenas a arquivos de texto, mas também a arquivos binários. Para detectar as diferenças entre os arquivos, o rsync os subdivide em blocos e calcula seus checksums.

O esforço dedicado à detecção das mudanças tem um preço. Os sistemas a serem sincronizados devem ser dimensionados generosamente para uso do rsync. A RAM é especialmente importante.

Dois modelos diferentes são comumente usados para distribuir dados. No primeiro modelo, todos os clientes sincronizam seus arquivos com um servidor central. O servidor deve ser acessível a todos os clientes pelo menos ocasionalmente. Esse modelo é usado pelo CVS.

A outra possibilidade é deixar todos os hosts ligados em rede sincronizarem seus dados entre os pontos uns dos outros. O rsync funciona de fato no modo cliente, mas qualquer cliente também pode atuar como servidor.

O CVS e o rsync também estão disponíveis para muitos outros sistemas operacionais, incluindo vários sistemas Unix e Windows.

No CVS, a sincronização de dados começa manualmente pelo usuário. Isso permite um controle fino dos dados a serem sincronizados e um fácil gerenciamento de conflitos. No entanto, se os intervalos de sincronização forem muito longos, será mais provável que ocorram conflitos.

Conflitos só ocorrem raramente no CVS, mesmo quando há muitas pessoas trabalhando em um grande projeto de programa. Isso ocorre porque os documentos são fundidos na base de linhas individuais. Quando ocorre um conflito, somente um cliente é afetado. Normalmente, os conflitos no CVS podem ser facilmente resolvidos.

Não há gerenciamento de conflitos no rsync. O usuário é responsável por não sobregravar acidentalmente arquivos e resolver manualmente todos os possíveis conflitos. Para fins de segurança, é possível empregar adicionalmente um sistema de controle de versão como o RCS.

No CVS, diretórios e arquivos novos devem ser adicionados explicitamente com o comando cvs add. Esse procedimento resulta em um maior controle do usuário sobre os arquivos a serem sincronizados. Por outro lado, os arquivos novos quase sempre são despercebidos, principalmente quando os pontos de interrogação na saída de cvs update são ignorados por causa do grande número de arquivos.

Um recurso adicional do CVS é a possibilidade de reconstrução de versões antigas de arquivos. Um breve comentário de edição pode ser inserido em cada mudança, e o desenvolvimento dos arquivos pode ser facilmente rastreado posteriormente com base no conteúdo dos comentários. Essa é uma ajuda valiosa para textos de teses e de programas.

Os discos rígidos de todos os hosts envolvidos devem ter espaço em disco suficiente para todos os dados distribuídos. O CVS requer espaço adicional para o banco de dados de repositório no servidor. O histórico do arquivo também é armazenado no servidor, requerendo ainda mais espaço. Quando arquivos em formato de texto são mudados, somente as linhas modificadas são gravadas. Arquivos binários requerem espaço em disco adicional relativo ao tamanho do arquivo sempre que ele for mudado.

Usuários experientes normalmente executam o CVS a partir da linha de comando. Entretanto, há interfaces gráficas do usuário disponíveis para Linux (como a cervisia) e para outros sistemas operacionais (como a wincvs). Muitas ferramentas de desenvolvimento e editores de texto (como o Emacs) oferecem suporte a CVS. É sempre mais fácil realizar a resolução de conflitos com esses front ends.

O rsync é bastante fácil de usar, sendo também adequado para principiantes. O CVS é um pouco mais difícil de operar. Os usuários devem entender a interação entre o repositório e os dados locais. As mudanças dos dados devem ser primeiro fundidas localmente no repositório. Esse procedimento é feito com o comando cvs update. Em seguida, os dados devem ser enviados de volta ao repositório com o comando cvs commit. Depois de compreender esse procedimento, os usuários principiantes também serão capazes de usar o CVS com facilidade.

Durante a transmissão, o ideal é proteger os dados contra interceptação e manipulação. É muito fácil usar o CVS e o rsync por SSH (shell seguro), proporcionando segurança contra ataques desse tipo. A execução do CVS via rsh (remote shell) deve ser evitada. O acesso ao CVS com o mecanismo pserver em redes desprotegidas também não é recomendável.

O CVS tem sido usado por desenvolvedores por um longo tempo para gerenciar projetos de programas e é extremamente estável. Como o histórico do desenvolvimento é gravado, o CVS fornece proteção até mesmo contra certos erros do usuário, como uma exclusão não intencional de um arquivo.

O servidor é o host em que todos os arquivos válidos se localizam, incluindo as versões mais recentes de todos os arquivos. Qualquer estação de trabalho estacionária pode ser usada como um servidor. Se possível, os dados do repositório do CVS devem ser incluídos em backups regulares.

Durante a configuração de um servidor CVS, é uma boa ideia conceder aos usuários o acesso ao servidor via SSH. Se o usuário for conhecido pelo servidor como tux e o software do CVS estiver instalado tanto no servidor quanto no cliente, as variáveis de ambiente a seguir deverão ser definidas no lado do cliente:

CVS_RSH=ssh CVSROOT=tux@server:/serverdir

O comando cvs init pode ser usado para inicializar o servidor CVS no lado cliente. Esse procedimento deve ser executado apenas uma vez.

Finalmente, é necessário designar um nome à sincronização. Selecione ou crie um diretório no cliente para conter arquivos a serem gerenciados com o CVS (o diretório também pode ficar vazio). O nome do diretório também será o nome da sincronização. Neste exemplo, o diretório é chamado de synchome. Vá para esse diretório e digite o comando a seguir para definir o nome de sincronização como synchome:

cvs import synchome tux wilber

Vários comandos do CVS requerem um comentário. Para essa finalidade, o CVS inicia um editor (o editor definido na variável do ambiente $EDITOR ou vi, se nenhum editor tiver sido definido). A chamada do editor pode ser evitada se você inserir o comentário antes na linha de comando, como no exemplo a seguir:

cvs import -m 'this is a test' synchome tux wilber

O repositório de sincronização agora pode ter a saída registrada de todos os hosts com cvs co synchome. Esse procedimento cria um novo subdiretório synchome no cliente. Para confirmar suas mudanças ao servidor, vá para o diretório synchome (ou um de seus subdiretórios) e digite cvs commit.

Por padrão, todos os arquivos (incluindo subdiretórios) são confirmados no servidor. Para confirmar apenas determinados arquivos ou diretórios individuais, especifique-os como em cvs commit arquivo1 diretório1. É necessário adicionar novos arquivos e diretórios ao repositório com um comando como cvs add arquivo1 diretório1 antes de confirmá-los no servidor. Depois disso, confirme os arquivos e diretórios recém-adicionados com cvs commit arquivo1 diretório1.

Se você for para outra estação de trabalho, registre a saída do repositório de sincronização, caso isso não tenha sido feito em uma sessão anterior na mesma estação de trabalho.

Inicie a sincronização com o servidor com cvs update. Atualize arquivos ou diretórios individuais como em cvs update arquivo1 diretório1. Para ver a diferença entre os arquivos atuais e versões armazenadas no servidor, use o comando cvs diff ou cvs diff arquivo1 diretório1. Use cvs -nq update para ver quais arquivos podem ser afetados por uma atualização.

Estes são alguns símbolos de status exibidos durante uma atualização:

O status M indica um arquivo modificado localmente. Envie a cópia local para o servidor ou remova o arquivo local e execute a atualização novamente. Nesse caso, o arquivo ausente será recuperado do servidor. Se você enviar um arquivo modificado localmente e ele tiver sido mudado na mesma linha de comando e enviado, poderá haver um conflito, indicado por C.

Nesse caso, observe as marcas de conflito (“>>” e “<<”) no arquivo e decida-se entre as duas versões. Como essa tarefa pode ser desagradável, você pode abandonar as mudanças, apagar o arquivo local e digitar cvs up para recuperar a versão atual do servidor.

O rsync pode ser operado em dois modos diferentes. Ele pode ser usado para arquivar ou copiar dados. Para fazer isso, apenas um shell remoto, como o SSH, é necessário no sistema de destino. Entretanto, o rsync também pode ser usado como um daemon para fornecer diretórios à rede.

O modo de operação básica do rsync não requer qualquer configuração especial. O rsync permite diretamente o espelhamento de diretórios inteiros em outro sistema. Como exemplo, o comando a seguir cria um backup do diretório pessoal do tux em um servidor de backup chamado de sun:

rsync -baz -e ssh /home/tux/ tux@sun:backup

O comando a seguir é usado para reproduzir o diretório de volta:

rsync -az -e ssh tux@sun:backup /home/tux/

Até esse ponto, o gerenciamento não é muito diferente do de uma ferramenta de cópia comum, como o scp.

O rsync deve ser operado no modo “rsync” para que todos os recursos fiquem totalmente disponíveis. Isso é feito ao se iniciar o daemon rsyncd em mais de um sistema. Configure-o no arquivo /etc/rsyncd.conf. Por exemplo, para tornar o diretório /srv/ftp disponível com o rsync, use a seguinte configuração:

gid = nobody
uid = nobody
read only = true
use chroot = no
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log

[FTP]
        path = /srv/ftp
        comment = An Example

Em seguida, reinicie o rsyncd com systemctl start rsyncd.service. É possível também iniciar o rsyncd automaticamente durante o processo de boot. Para essa configuração, ative esse serviço no Gerenciador de Serviços do YaST ou manualmente, digitando o comando:

root #  systemctl enable rsyncd.service

Se preferir, inicie o syncd pelo xinetd. Entretanto, isso só é recomendável para servidores que raramente usam o rsyncd.

O exemplo também cria um arquivo de registro listando todas as conexões. Esse arquivo é armazenado em /var/log/rsyncd.log.

Então será possível testar a transferência de um sistema cliente. Faça isso com o seguinte comando:

rsync -avz sun::FTP

Esse comando lista todos os arquivos presentes no diretório /srv/ftp do servidor. Essa solicitação também é registrada no arquivo de registro /var/log/rsyncd.log. Para iniciar uma transferência real, forneça um diretório de destino. Use . para o diretório atual. Por exemplo:

rsync -avz sun::FTP .

Por padrão, nenhum arquivo será apagado durante a sincronização com o rsync. Se esse procedimento for forçado, a opção adicional --delete deverá ser expressa. Para garantir que nenhum arquivo novo seja apagado, use a opção --update como alternativa. Qualquer conflito ocorrido deve ser resolvido manualmente.