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

Re: Confusion over vender version updates.

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-06-07 06:25:08 CEST

On Jun 6, 2007, at 05:07, David Kastrup wrote:

> David Wyles writes:
>> In the SVN book (http://svnbook.red-bean.com/nightly/en/
>> svn.advanced.vendorbr.html) the following is said for when
>> updating a vender
>> library with a new version:
> [...]
>> My issue is with the following:
>> ?svn status will show files with local modifications as well as,
>> perhaps, some
>> unversioned or missing files?
>> How can it show missing files when the previous paragraph said:
>> ?We quite literally copy new files on top of existing files?
> That paragraph is nonsense. One should remove the whole tree with the
> exception of the .svn directory.

This has been brought up on this list before.


However, feedback about the book should be given to the book's
mailing list.


>> Or Leaving the .svn directories intact and physically delete the
>> previous
>> version files from the file system (not subversion) and then copy
>> the new
>> version over the top. svn status will now show the deleted files
>> with ?!?
>> symbol.
>> Is there a better way? And does the book need correcting?
> Well, there is a better way, i guess. Check in the original tree into
> Subversion. Remove your working copy. Export the original tree with
> mkdir mytree
> cd mytree
> git-svn init svn://whatever
> git-svn fetch
> Now unpack your new tree here. Do
> git-add .
> git-commit
> git-svn dcommit
> Something like that. I am just a starter with git, so you'd better
> experiment yourself. However, one of the main strengths of git is
> that it deals with copied and renamed files and split files (move some
> function elsewhere) while maintaining the history, without the user
> having to tell git about it.
> That is quite different to Subversion where you need to tell
> Subversion what you are doing to the files if it is supposed to track
> them. Using git for preparing your Subversion commits will manage to
> track this kind of info for you.

I think it's a bit weird to bring git, a whole different version
control system, into the picture at this point.

To the original David: the svn_load_dirs.pl script exists to simplify
the process of importing new vendor code into your Subversion repo.
I've used it a lot and it works pretty well.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 7 06:25:59 2007

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.