Joel Yliluoma <bis### [at] ikifi> wrote:
> On 11 Apr 2012 05:57:16 -0400, Warp wrote:
> > Copy an unversioned directory from somewhere else onto a
> > versioned directory in your project? Svn breaks.

> Actually that does not break Svn. Those are just files
> that Svn does not track. But the other points you mentioned
> are quite valid.

  I didn't express the situation clearly enough there.

  What I meant is that you have a directory in your project that *is*
versioned, and another with the same name somewhere else that isn't. If
you now copy that other, unversioned directory into your project (ie.
replacing the contents of the versioned directory), svn breaks.

  It breaks because it expects that directory you just replaced the contents
of to have .svn subdirectories inside (at each subdirectory level), but
they have disappeared. It will refuse to let you add this new subdirectory
structure to the project (because it's "already there" according to the
remote repository information), and it will likewise refuse to update to
the version that's at the remote repository (because it would overwrite
these "unversioned" files).

  The only way to fix the situation is to remove the offending directory
structure completely, then update (now it complies because no local
unversioned files are being overwritten) and then you have to copy the
individual files from that other directory here, one subdirectory at a
time.

  One could hastily think that why one would even do that. However, it can
be more common than one might think.

  For example, you may have some third-party library in your project, which
your project uses. This third-party library is in a directory structure.
Then you download a newer version of the library, unpack it, and then copy
or move this newer version into your project... And it breaks (because these
new directories do not have the proper .svn subdirectories inside them).

  (Of course this can be avoided eg. by copying the new version into a
directory with a different name, eg. a name with the library's version
in it, and then have a soft link that always points to the newest version
of said library. In my particular case this is not a very working solution
because Xcode doesn't support soft links very well, and it tends to break
if I try this. Nevertheless, a versioning system shouldn't break when doing
this kind of thing which isn't even all that uncommon.)

-- 
                                                          - Warp

Post a reply to this message