When using full URL with @ notation HEAD is still checked out from SVN about djangorecipe HOT 6 CLOSED

(by shanx)
I've found out why this was the case. Using the link with a trailing slash: http://code.djangoproject.com/svn/django/trunk/@7943 instead of the one in the recipe above results in the required behaviour. Question remains now: is this actually a bug in djangorecipe?

from djangorecipe.

(by jvloothuis)
I did not experience this problem whilst trying to reproduce it. Does a checkout with the / version work for you when you use svn directly?

from djangorecipe.

(by shanx)
On Tue, Jul 22, 2008 at 11:13 PM, Jeroen Vloothuis <
> wrote:

I did not experience this problem whilst trying to reproduce it. Does a
checkout with the / version work for you when you use svn directly?

I don't have time to write a testcase for this now, but I've been able to
reproduce this: the error only occurs when running the buildout command more
then once.

So first buildout runs ok.
The second updates to the last revision.

This error can be lead back (I think) to line 180 in
/src/djangorecipe/init.py:

                if self.command('svn up %s' % download_location):

This svn up command doesn't do anything with a version used in the SVN url.

Remco

Maykin Media
Damrak 355, 1012 ZJ Amsterdam
tel.: +31 (0)6 187 967 06
http://www.maykinmedia.nl

from djangorecipe.

(by jvloothuis)
This has now been fixed in trunk.

from djangorecipe.

(by shanx)
This bug is unfortunately still a problem, though the improved update function by itself works like a charm (as shown by the unit tests). The update function in the recipe is never called, instead the recipe does an uninstall and then an install of django. So the svn up being called is the one from install_svn_version.

from djangorecipe.

(by jvloothuis)
This problem was caused by creating a random secret in the init and storing it in the options dict. This made buildout think that it should always uninstall and install since the options had been changed.

from djangorecipe.