#include <hallo.h> * Joey Hess [Fri, Sep 12 2003, 11:27:23AM]: > First of all, I cannot use the program, because I do not keep my sources > in a directory called trunk. My sources are in ~/src, which is pulled in > by a set of svn:externals from various locations in three subversion > repositories. > > I also do not keep my orig tarballs in subversion, for reasons of both > space and bandwidth. I was suprised to find that your svn-uupdate required It doesn't require this. It is a recommendation and svn-inject adds it with the -i switch. Feel free to remove tarballs directory from the repository but keep it localy. svn-uupdate will take care of it (IIRC) and no longer add tarballs to the repository. > What really suprised me is that you don't use svn_load_dirs. For all its I didn't like it - IMHO overkill for my purpose. Afterwards, I think I should have used it. > warts, it is very useful, especially when upstream moves files around. I > also suspect that it is far more efficient than is your method. You run It is. I will look on how it exactly works and decide wheter I keep my code or use svn_load_dirs though. > one svn add or remove for every new or deleted file in the new upstream > source. Some of us have our subversion server on the other side of a > modem, and opening possibly hundreds of ssh connections is a pain. This argument is pointless, rewritting this to work with one call is a job of few seconds/minutes. > technique also won't properly handle files that were in the old upstream > version, are in the new one, but were deleted from the debian > repository. I belive it will re-add those files, whereas svn_load_dirs > will not. Nope, svn does not re-add them. However, I will consider switching to svn_load_dirs since it seems to be more mature. > If it's run with a parameter, it replaces the trunk with that parameter: > > joey@dragon:~/src/debhelper>svnpath tags > svn+ssh://kitenet.net/home/svn/debhelper/tags > joey@dragon:~package/uqm>svnpath branches > svn+ssh://kitenet.net/home/svn/uqm/branches/uqm > > I find this very useful in general packaging work, since it saves me > needing to type out long subversion urls all the time. And with this Sounds useful; AFAICS you are used to have a directory layout different to the one in the repository why my scripts rely on the same structure. Btw, your script files in my layout. > simple program, a program like svn-uupdate can guess at the paths for > tags and branches, and get them right with ease. Of course there are > some variations. For example, I keep my latest upstream branch in > `svnpath branches`/upstream. (For debhelper this is > svn+ssh://kitenet.net/home/svn/debhelper/branches/upstream, while for > uqm, this is svn+ssh://kitenet.net/home/svn/uqm/branches/uqm/upstream.) Okay, I will consider this when making changes in svn-uupdate. Working on local directories is, in fact, asking for trouble and forces to keep the same directory structure in the repository, not flexible enough. I will change this soon to act the way you wished above. > Still, you'll find that my svn-uupdate script only contains at most three > variables that may need to be customized. (And it'd not be hard to reduce this > to only two.) I put these up front, and they could also be controlled by > switches, to accomidate _really_ weird repo layouts. Sure. > # You may need to change these expressions to match your repo. > tagurl=`svnpath tags`/upstream_version_$upstream_version > oldupstreamurl=`svnpath tags`/upstream_version_$oldupstream_version > upstream_branch=`svnpath branches`/upstream And this also may become an option. I can imagine a config file in $HOME where such schemes are defined for local directories, and svn-uupdate/svn-buildpackage take the right one depending on the start directory. > By virtue of using svn_load_dirs, my svn-uupdate implementation is > short, just 65 lines. By virtue of using svnpath, it is nearly > repository independant. It does lack a few features, like importing > tarballs and baz2 (it currently imports only unpacked directories). I'd > be glad to add these features though. I've attached the program to this > message; the most recent copy is svn://kitenet.net/joey/trunk/bin/svn-uupdate As said, I fail to see the reason to be glad about it. The local-path/svn-path independence can be easily achieved with a simple sub routine. On the contrary, I dislike having a random mixture of perl-over-shell-over-perl-with-shell-calls. MfG, Eduard.
Attachment:
pgpmkiFoDHTzX.pgp
Description: PGP signature