[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.

http://svn.haxx.se/users/archive-2005-12/1068.shtml

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

http://www.red-bean.com/mailman/listinfo/svnbook-dev

>> 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.