[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Log entry missing 'name' attribute (entry 'upgrade-format' for directory 'master')

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-08-24 21:55:33 CEST

On 8/23/07, Anders Schau Knatten <anders@knatten.org> wrote:
> On Wed, 22 Aug 2007 14:54:04 +0200, Erik Huelsmann <ehuels@gmail.com>
> wrote:
>
> > On 8/22/07, Anders Schau Knatten <anders@knatten.org> wrote:
> >> Hi,
> >>
> >> I have a locked directory, and trying to do svn cleanup I get the
> >> following message:
> >> Log entry missing 'name' attribute (entry 'upgrade-format' for directory
> >> 'master')
> >>
> >> I have tried to edit .svn/log and add an empty 'name' attribute to that
> >> entry, but then svn cleanup complains:
> >> svn: Unrecognized logfile element 'upgrade-format' in '.'
> >
> > You're mixing client versions to access your working copy: a 1.4
> > client may write the 'upgrade-format' command to your working copy.
> > Only 1.3 or earlier clients don't know what to do with it.
> >
> > So, you got your WC in this state with a 1.4+ client and it looks like
> > you're trying to get out of the situation using an older client.
> >
> > To resolve the issue, try running 'svn cleanup' using a 1.4 client.
> >
> > There's a bit of a weird thing though: your log contains an awful lot
> > of 'rm' commands yet it doesn't look like a log which may have
> > resulted from a commit operation. What are you trying to do?
>
> You are right about the conflicting clients. I use 1.3 on one of my boxes
> (let's call it A), but I have mounted the same filesystem via sshfs on my
> laptop (lets' call it B), which has 1.4 installed. I have not worked on
> these files for quite a while. So long actually, that I do not remember
> everything I did before. This was also before I started using sshfs.
>
> Now I just wanted to do "svn up" and "svn ci". I ended up just checking
> out a fresh copy into a new directory, copying the few changed files here,
> and then check in. I did all of this on A. That worked nicely.
>
> There seems to be some problems with using svn on top of sshfs on B
> however. When trying to checkout a fresh copy into a new directory
> I get the following error:
>
> $ svn co svn+ssh://myhost.org/svn/myproject/trunk testdirectory
> svn: Can't move 'testdirectory/.svn/tmp/entries' to
> 'testdirectory/.svn/entries': Operation not permitted

Subversion expects to be allowed to rename files on top of existing
files. All filesystems we know of allow it. We need that feature to be
able to keep the working copy in a sane/known state at all times. If
sshfs doesn't provide that feature, then, if you want to use it with
Subversion, you'll need to add it.

You can't mix access to working copies between 1.4 and 1.3 though: 1.4
will upgrade the format to 8 and 1.3 doesn't know about that format...

> This only happens when I am inside the sshfs-mounted part of my
> filesystem, when inside a part of the filesystem that resides on the local

Yes, as I said, all filesystems we know of allow renaming files on top
of existing files...

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 24 21:53:09 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.