Top posting:
The cause of the problem with leading spaces in property names is
probably found. It was the use of Vss2Svn with an unfortunate
auto_props file that generated a dumpfile which was accepted by the
svnadmin load command.
The perl below shows how vss2svn reads the auto_prop-file. As I
understand the split command, everything but the splitter is kept
(including the space):
http://www.pumacode.org/projects/vss2svn/browser/trunk/script/Vss2Svn/Dumpfile/AutoProps.pm?rev=329#L58
my @props = split ';', $autoprop;
foreach my $prop (@props)
{
my ($key, $value) = split '=', $prop;
$newprops{$key} = $value;
}
I don't know how safe svnadmin load is supposed to be. If the dumpfile
only is supposed to be generated by svnadmin dump, I don't think
better error handling is of high priority.
Thanks again for all the help!
/$
2007/12/26, Henrik Sundberg <storangen@gmail.com>:
> 2007/12/26, Ryan Schmidt <subversion-2007b@ryandesign.com>:
> > On Dec 24, 2007, at 04:30, Henrik Sundberg wrote:
> >
> > > On 2007/12/22, Henrik Sundberg wrote:
> > >
> > >> I have a property name with a leading space. I can not get rid of it.
> > >>
> > >> (I have a swedish installation. I've tried to translate the output)
> > >>
> > >> Proplist gives:
> > >> C:\wc>svn proplist mydoc.doc
> > >> Properties for "mydoc.doc":
> > >> svn:needs-lock
> > >> svn:needs-lock
> > >> svn:mime-type
> > >>
> > >> The second needs-lock is the result from trying to set the property
> > >> correctly. I have no idea how the first was entered into the
> > >> repository. We use the 1.4.5 client and 1.4.4 server.
> > >>
> > >> I think this gives the following error when trying to open the
> > >> document via TortoiseSvn Show Log (the problem was not fixed by
> > >> changing according to
> > >> http://svn.haxx.se/users/archive-2004-01/0980.shtml, and other
> > >> documents can be opened this way):
> > >> PROPFIND request failed on
> > >> '/repos/myrepo/!svn/bc/9594/myproj/trunk/docs/mydoc.doc'PROPFIND of
> > >> '/repos/myrepo/!svn/bc/9594/myproj/trunk/docs/mydoc.doc': 207
> > >> Multi-Status (http://myrepo_svn)
> > >>
> > >> This is what I've been trying to do:
> > >> C:\wc>svn propdel svn:needs-lock mydoc.doc
> > >> The property "svn:needs-lock" deleted from "mydoc.doc".
> > >>
> > >> C:\wc>svn proplist mydoc.doc
> > >> Properties for "mydoc.doc":
> > >> svn:mime-type
> > >>
> > >> C:\wc>svn ci -m "Deleting erroneous property" ..\wc
> > >> Sends mydoc.doc
> > >> svn: Commit failed (more info follows) (was: svn: Arkiveringen
> > >> misslyckades (mer information följer):)
> > >> svn: At least one property change failed; repository unchanged (was:
> > >> svn: Åtminstone en egenskapsändring misslyckades; arkivet är
> > >> oförändrat)
> > >>
> > >> C:\wc>svn propedit " svn:needs-lock" mydoc.doc
> > >> svn: Erroneous property name: " svn:needs-lock" (was: svn: Felaktigt
> > >> egenskapsnamn: " svn:needs-lock")
> > >>
> > >> C:\wc>svn propdel "svn:needs-lock" mydoc.doc
> > >> The property "svn:needs-lock" deleted from "mydoc.doc".
> > >>
> > >> C:\wc>svn propdel " svn:needs-lock" mydoc.doc
> > >> The property " svn:needs-lock" deleted from "mydoc.doc".
> > >>
> > >> C:\wc>svn proplist mydoc.doc
> > >> Properties for "mydoc.doc":
> > >> svn:mime-type
> > >>
> > >> C:\wc>svn ci -m "Deleting erroneous property" ..\wc
> > >> Sends mydoc.doc
> > >> svn: Commit failed (more info follows) (was: svn: Arkiveringen
> > >> misslyckades (mer information följer):)
> > >> svn: At least one property change failed; repository unchanged (was:
> > >> svn: Åtminstone en egenskapsändring misslyckades; arkivet är
> > >> oförändrat)
> > >
> > > Does anyone have a clue on this? Can a property with a space in the
> > > name be deleted? There are several files like this, so my guess is
> > > that an administrator ran a script of some kind.
> > > Is there anything I should look up to provide better information?
> > >
> > > I don't have access to the repository from here. My only idea now is
> > > to locate the changeset in which the erroneous property occured and
> > > try to revert it. Do you think that would work or will the revert fail
> > > due to the same reasons that makes it fail now?
> > >
> > >
> > > Or do I have to dump the repository? If I change the dump, will a
> > > repository built from the dump keep the same revision numbering? (The
> > > numbering is important, when using Trac, isn't it? Isn't that the glue
> > > between tickets and the repository?)
> > >
> > > Sorry if I'm too vague.
> >
> > Hi Henrik. You're not being vague at all, I just didn't respond
> > before because I hadn't had a chance to test it.
> >
> > You can't "revert" the problematic changeset; "revert" is only for
> > changes that have not yet been committed. To undo committed changes,
> > you would need to do a reverse merge, and I'm sure either that or the
> > subsequent commit would fail for the same reasons as your current
> > manual trials.
> >
> > I'm trying to recreate the situation with the file with the bad
> > property name. I can't do it using a simple propset:
> >
> > $ svn propset ' svn:needs-lock' '*' foo.bar
> > svn: Bad property name: ' svn:needs-lock'
> > $
> >
> > I also tried various incorrect syntaxes in the auto-props section of
> > the ~/.subversion/config file (using extra spaces, incorrect quoting
> > and so on) and was unable to get a property name with a space onto a
> > file.
> >
> > I'm using Subversion 1.4.6. Maybe the "Bad property name" check was
> > added to Subversion at some point, and you were using a version
> > earlier than that when the bad property name was added? If so, you
> > could try deleting the bad property with that older version of
> > Subversion. I'm not sure whether it's the server or client or both
> > that would have to be running this older version to do this.
> >
> > You could also try fiddling with a dump of the repository. dumpfiles
> > aren't meant to be edited by hand, but fortunately someone wrote a
> > nice Python script to help you edit dumpfiles:
> >
> > http://svn.borg.ch/svndumptool/
> >
> > I looked through the readme listing all the things svndumptool can
> > do. It doesn't have a function to do exactly what you want, but it
> > has one that's close: it can go through and change the *value* of a
> > certain property for all files in your dumpfile. I imagine you could
> > fairly easily modify svndumptool so that it could change the *name*
> > of a property in all files instead, so you could change the property
> > name to remove the leading space. Umm... that might be a problem if
> > you already have the correctly-named "svn:needs-lock" property on
> > those files though. Well, you could rename the property to "foo" and
> > then after you load the dumpfile back in, you could remove the
> > property "foo" from all files. Or maybe you could modify
> > svndumpfilter further so that it can delete properties of a given
> > name. That might actually be a useful general purpose feature to have
> > in svndumpfilter. Maybe the author of the tool would even help you
> > implement it.
> >
> > Once you've fixed the problem, you could install a pre-commit hook to
> > prevent the commit of any file that has a property with a space at
> > the beginning of its name. Clearly currently versions of Subversion
> > already prevent this on their own, but you could do this if you want
> > to be absolutely sure it never happens again.
>
> Thanks a lot for the suggestions!
> I'll tell my admin to check out the dumpfile tools. He should also
> know which SVN version that was used when the erroneous properties
> occured.
>
> Henrik
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 27 21:38:46 2007