[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: svn-uupdate approaches

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


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

> 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


Attachment: pgpmkiFoDHTzX.pgp
Description: PGP signature

Reply to: