On Dec 12, 2005, at 19:57, Marcus Crafter wrote:
> We're about to start using a product available via Subversion as
> the base for a new project. Since we're using Subversion
> internally, I'd like to be able to take the remote sources and
> check them in locally so that we can work on them and (due to the
> structure of the project) modify them.
>
> Once we've committed the sources locally, is there any way we can
> still monitor the original upstream repository for changes? and
> import them as we'd like?
>
> I'm not sure if Subversion offers such a feature but any process
> that would allow us to do this would be great (ie. modify the
> sources and check them in locally, but still monitor the remote
> repository for updates).
>
> The only way I can think of doing this is via patches, but I'd
> rather not maintain patches to the external sources as if they
> change regularly we'll be needing to update our patches more often
> than what we'd like.
>
> Any thoughts? Has anyone had this requirement before at all?
You can use vendor branches for this.
http://svnbook.red-bean.com/en/1.1/ch07s05.html
The book will talk about taking the tarball distributed by the
project, importing that into your own area called vendor, and then
copying that in the repository, and modifying your copy. When a new
version of the project is imported into the vendor section, you can
then use svn merge to easily update your modified copy.
Since the foreign project also uses Subversion, you should be able to
skip the fiddly importing bit and just do merges directly out of
their repository.
To do the initial import, get an export of their repository and
import it into yours, noting the revision number:
svn export \
http://www.theirproject.com/svn/theirproject/trunk \
/tmp/theirproject
svn import /tmp/theirproject \
http://www.yourserver.com/svn/yourcopyoftheirproject \
-m "Importing theirproject trunk r4200"
rm -rf /tmp/theirproject
svn checkout \
http://www.yourserver.com/svn/yourcopyoftheirproject
Now you can make changes as you like in yourcopyoftheirproject and
commit these to your repository.
When you want to resynchronize with their repository, you can merge
their changes into your working copy and commit. First you need the
current revision number of theirproject:
svn info \
http://www.theirproject.com/svn/theirproject/trunk \
| grep -E '^Revision:' | cut -d " " -f 2
Suppose this outputs "4345". Now you merge the changes from 4200 (the
last revision you merged, which you should have written in your svn
log message for your own convenience) to 4345 (the current version)
into yourcopyoftheirproject:
cd yourcopyoftheirproject
svn merge -r4200:4345 \
http://www.theirproject.com/svn/theirproject/trunk .
svn commit \
-m "Merging r4200-4345 of theirproject into yourcopyoftheirproject"
Note that I haven't tried any of this, but it seems to me like it
should work.
In the event that it doesn't, you can go back to following the vendor
branch instructions more closely, ignoring the fact that theirproject
has a Subversion repository at all and just downloading tarballs from
them and using svn_load_dirs. Or, you can keep a working copy of
theirproject and do svn exports from it, and run svn_load_dirs on the
exports.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 19 15:47:29 2005