You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Erik Forsberg <fo...@cendio.se> on 2006/08/11 06:47:32 UTC
New vendor drops on vendor branch - but how?
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?
Thanks,
\EF
(Sorry if this message arrives twice - tried to post via gmane
yesterday, but the message didn't come through)
--
Erik Forsberg OpenSource-based Thin Client Technology
Systems Analyst/Developer Phone: +46-13-21 46 00
Cendio AB Web: http://www.cendio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: New vendor drops on vendor branch - but how?
Posted by Johan Appelgren <jo...@gmail.com>.
On 8/11/06, Erik Forsberg <fo...@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
Re: New vendor drops on vendor branch - but how?
Posted by Bob Proulx <bo...@proulx.com>.
Gavin Lambert wrote:
> > find . -type d -name .svn -prune -o -type f -print0 | xargs -r0 ls -ldog
> Yes, someone else suggested the same thing the next day.
>
> I didn't like the find with grep either, but (since I had forgotten the
> '-o -type f -print' bit) using just -prune resulted in printing all the
> .svn folders, not all *but* the .svn folders. I was in a hurry, so I
> didn't have time to experiment much further :)
>
> The man page I've got on find wasn't particularly forthcoming either,
> and didn't explain how -prune interacts with the other options.
The -prune option causes find to stop recursing down that path. This
prevents find from walking down the .svn directories. And it returns
true like almost all other find options. True and false are important
because find executes the -options as a little program. The -o and -a
generate OR and AND constructs with short-circuit logical evaluation
of the booleans.
find . -- walk all of the directores below here
-type d -- true if a directory, false if not
-name .svn -- if here after -type d above then must be a directory
with name .svn, effectively -type d AND -name .svn
since the AND is always implied
-prune -- if here after above stop traversing and skip this dir,
return true
-o -- a logical OR. if the above was true then because true
OR anything is true stop evaulating. if false for
any of reason then evaulate right-hand-side of OR
-- RHS of OR here
-type f -- true if a file, false if not
-print0 -- if here after above then must be a file
print the path null terminated
The AND is the default connection between options. But this could be
written more verbosely with all of the implied ANDs like this.
find . -type d -and -name .svn -and -prune -or -type f -print
But I actually find that much harder to read, not easier, and so I
prefer the previous.
find . -type d -name .svn -prune -o -type f -print
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: New vendor drops on vendor branch - but how?
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth Bob Proulx <ma...@proulx.com>:
> Gavin Lambert wrote:
>> I haven't tried this myself (so try it without the 'rm' first to make
>> sure it gives the right results!), but this ought to remove all files
>> except for the .svn folders, starting from the current directory:
>>
>> find . | grep -v .svn | xargs rm -f
>
> That find command with "grep" looks very suspicious to me.
> Perhaps you wanted to suggest something like this instead?
>
> find . -type d -name .svn -prune -o -type f -print0 | xargs -r0 ls
> -ldog
>
> And after inspecting for safety then replace the "ls -ldog"
> with "rm -f"?
Yes, someone else suggested the same thing the next day.
I didn't like the find with grep either, but (since I had forgotten the
'-o -type f -print' bit) using just -prune resulted in printing all the
.svn folders, not all *but* the .svn folders. I was in a hurry, so I
didn't have time to experiment much further :)
The man page I've got on find wasn't particularly forthcoming either,
and didn't explain how -prune interacts with the other options.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: New vendor drops on vendor branch - but how?
Posted by Bob Proulx <bo...@proulx.com>.
Gavin Lambert wrote:
> I haven't tried this myself (so try it without the 'rm' first to make
> sure it gives the right results!), but this ought to remove all files
> except for the .svn folders, starting from the current directory:
>
> find . | grep -v .svn | xargs rm -f
That find command with "grep" looks very suspicious to me. Perhaps
you wanted to suggest something like this instead?
find . -type d -name .svn -prune -o -type f -print0 | xargs -r0 ls -ldog
And after inspecting for safety then replace the "ls -ldog" with "rm -f"?
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: New vendor drops on vendor branch - but how?
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth Erik Forsberg <ma...@cendio.se>:
> 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.
[...]
> 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.
Yep, it's definitely a bit confusing in that spot.
I haven't tried this myself (so try it without the 'rm' first to make
sure it gives the right results!), but this ought to remove all files
except for the .svn folders, starting from the current directory:
find . | grep -v .svn | xargs rm -f
(if you've got files with '.svn' in them for some weird reason, you can
use '/.svn' to cut down the results a bit.)
And note that this will find *all* files, not just version-controlled
ones. So make sure you're doing it in the right place, and you don't
have any unversioned files you care about!
After untarring the vendor drop, you'd have to manually enter any
copies/moves/renames afterwards, though, which'd be a bit painful.
svn_load_dirs.pl is a bit less painful in this regard :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org