[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

add vs delete question

From: Oblio <subscriber_at_locustcreek.com>
Date: 2006-05-04 15:42:20 CEST

I've got a question about a passage in the online
book. In chapter 7: vendor branches, it states,

"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­we
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."

Now, I've highlighted the part that doesn't seem
to fit. The 'add' command is pretty simple and
straight-forward; it will find missing
files/directories and put them under version
control. However, if I've just exploded a
tarball over the top of my code, it doesn't
automatically mark things to be deleted. I would
actually have to expand it to a different
directory and run some utility to find missing
files, compile that into a script and run the
'delete' command using the script.

Am I correct? Or is there an easier way?
Received on Thu May 4 15:43:51 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.