Confusion over vender version updates.

[David Wyles <dw...@mediagrids.com>]

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:

 

===

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.

===

 

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"

 

Thus the old files will still be there unchanged, and files that are in
the new version that haven't changed will also be there but unchanged.

 

To know what not in the latest version but is in the previous version
two options are open:

 

Comparing the two versions independently (i.e. in different directories)
and then deleting them using svn delete.

 

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?

 

David.

======================================

David Wyles - Technology is our speciality.

Technical Architect

www.mediagrids.com

 



This message has been scanned by MailController - www.MailController.altohiway.com

Re: Confusion over vender version updates.

[Talden <ta...@gmail.com>]

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


I thought the more precise definition was that you couldn't tell it about
renames, copies and moves and it simply guesses.  The neat side-effect is
that it might spot split files, the downside being that it might miss a
rename or incorrectly identify an add-remove pair as a rename.

There are a lot of things to like about git... I'm not yet convinced that
the implicit rename is a good one (and isn't the identification of renames
extremely expensive?)

Subversion needs to seriously consider git/mercurial/SVK strengths and think
about implementing many of them (in what would absolutely have to be a
Subversion 2.x) or shut up shop and accept that their membership is going to
dry up a bit.

Of course this is being discussed in some more current posts so it's not
worth discussing here...

In some ways the loaddirs script is making similar guess-work to git (as I
believe it tries to guess renames as well)... Because this is used primarily
for vendor check-ins you don't happen to care about the history and use the
script mainly for it's space/time optimisation.

--
Talden

Re: Confusion over vender version updates.

[Ryan Schmidt <su...@ryandesign.com>]

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

Re: Confusion over vender version updates.

[David Kastrup <da...@gnu.org>]

"David Wyles" <dw...@mediagrids.com> 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.

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

-- 
David Kastrup

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org