Subversion: working copy vs repositorio original

Hoy he estado mirando código añejo puesto en lo que yo creía que era un repositorio de Subversion… Estaba haciendo un dump para pasar el «formato» del antiguo Berkeley DB al nuevo FSFS, pero:

[j@localhost repositorios]$ svnadmin dump XXXX -q | svnadmin load vision-robotics-svn-fsfs/
svnadmin: E000002: Can't open file 'XXXX/format': No such file or directory
svnadmin: E200003: Premature end of content data in dumpstream

No tenía ni idea de lo que ocurría hasta que encontré este enlace:

Updated, 2009-07-23: Apparently it helps to be awake while doing this. The solution to the problem above is rather simple. svnadmin does not work on a checkout, but only on the real repository. So in case you are hosting with an external provider such as Unfuddle, Hosted Projects, CVSDude, Assembla and so on, you won’t be able to svnadmin dump on a working copy.

En repositorios centralizados (CVCS), como Subversion, el working copy contiene sólo el código. El historial se encuentra sólo en el servidor:

Subversion only maintains the revision you currently have checked out locally. (Some meta data about other revisions might be cached depending on your client, but the actual file content from other revisions will not be stored.) There’s no way to commit other than committing to the actual repository. Just a design difference of git vs subversion (centralized vs distributed).

Lo que tenía entre manos no era el repositorio central, sino un working copy:

[j@localhost XXXX]$ svn status --show-updates
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at 'repositorios/XXXX'
is too old (format 10) to work with client version '1.9.3 (r1718519)' (expects format 31). You need to upgrade the working copy first.

Como podemos esperar, tampoco se puede reconstruir el repositorio «original» central a partir del working copy: https://stackoverflow.com/questions/13324762/can-i-restore-a-deleted-svn-repository-from-a-local-check-out https://stackoverflow.com/a/13324839

The best you can do is setup a new repo, delete the .svn directories in your working copy, then import the files into the new repo. You will need to then go to any existing working copies and switch them to the new repo. You’ll probably need to do a switch –relocate.

https://stackoverflow.com/questions/1293692/recreating-svn-repository https://stackoverflow.com/a/1293740

The development history that was stored in your old repository is lost. You can create a new repository with the current contents of your working copy, but this will truly be a new repository. You can’t switch to it, not even with –relocate. If you’ve already managed to import the contents of your working copy into the new repository, you just need to check it out. If not: svn export WORKING_COPY WORKING_COPY.export # the exported copy will contain no .svn dirs svn import WORKINGCOPY.export svn://example.com/new-repository svn checkout svn://example.com/new-repository NEW_WORKING_COPY

No había trabajado antes con repositorios centralizados y este problema me ha hecho ver con más detalle su funcionamiento. Esto, como bien sabemos, no ocurre en repositorios distribuidos (DVCS) como Git o Mercurial.