On 8/11/06, Erik Forsberg <forsberg@cendio.se> wrote:
> Hi!
>
> I'm experimenting with vendor branches and subversion, trying to
> understand the documentation. I'm a bit confused on the procedure when
> it comes to doing new vendor drops.
>
> Quoting
> http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html:
>
> >To perform this upgrade, we checkout a copy of our vendor branch, and
> >replace the code in the current directory with the new libcomplex 1.1
> >source code. We quite literally copy new files on top of existing
> >files, perhaps exploding the libcomplex 1.1 release tarball atop our
> >existing files and directories. The goal here is to make our current
> >directory contain only the libcomplex 1.1 code, and to ensure that all
> >that code is under version control. Oh, and we want to do this with as
> >little version control history disturbance as possible.
> >
> >After replacing the 1.0 code with 1.1 code, svn status will show files
> >with local modifications as well as, perhaps, some unversioned or
> >missing files. If we did what we were supposed to do, the unversioned
> >files are only those new files introduced in the 1.1 release of
> >libcomplex\u2014we run svn add on those to get them under version
> >control. The missing files are files that were in 1.0 but not in 1.1,
> >and on those paths we run svn delete. Finally, once our current
> >working copy contains only the libcomplex 1.1 code, we commit the
> >changes we made to get it looking that way.
>
> What I don't understand in this instruction is how this is going to
> work for files that have been removed in the new release
> libcomplex. If the file foo/bar.c exists in the svn working-copy and I
> explode a tarball which _doesn't_ contain foo/bar.c on top of the
> working-copy, there will still be a foo/bar.c in the working-copy, and
> 'svn status' won't show it as missing.
>
> In order to get the desired behaviour, I'd need to clean the working
> copy of all files and directories. But as far as I can see, there's no
> good way to do that without confusing svn, or is there? If I do a 'rm
> -r' in my working-copy, svn will have no idea about what files were
> and weren't available in subdirectories, and it will also complain
> about files being missing if I try to tell it to move a file from one
> location to another.
>
> I know about the svn_load_dirs.pl script, but I'd still like to know
> how to do a vendor drop manually.
>
> Any thoughts on this?
To do it manually you'd have to manually go through all files and use
svn rm and svn mv to make the old layout match the new. The first
example in the book is simplified and ignores the fact that there may
be moves and deletes. It just tries the explain the general procedure.
The last paragraph explains this pretty well I think.
"But things aren't always that simple, and in fact it is quite common
for source files to get moved around between releases of software.
This complicates the process of ensuring that our modifications are
still valid for the new version of code, and can quickly degrade into
a situation where we have to manually recreate our customizations in
the new version. Once Subversion knows about the history of a given
source file—including all its previous locations—the process of
merging in the new version of the library is pretty simple. But we are
responsible for telling Subversion how the source file layout changed
from vendor drop to vendor drop."
/Johan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 11 09:40:28 2006