Solved [help] How to recover a mangled svn repository updated with svnup

Mjölnir

Mjölnir

I updated an existing svn(1) repository via svnup(8), unfortunately I didn't RTFM svnup(1) before... :eek: Now svnlite update fails:
Code: 
Updating '.':
   C stand/libsa/time.c
D    contrib/ipfilter/ipsend/linux.h
D    contrib/ipfilter/ipsend/slinux.c
D    contrib/ipfilter/ipsend/sirix.c
D    contrib/ipfilter/ipsend/larp.c
D    contrib/ipfilter/ipsend/lsock.c
svn: E000002: Unable to create pristine install stream
svn: E000002: Can't create temporary file from template '/src/13-CUR/.svn/tmp/svn-XXXXXX': No such file or directory
How can I recover? Or should I just switch to svnup completely (destroy .svn metadata directory)? It's the FreeBSD CURRENT source tree, I manage my changes via mount_unionfs(7) into my $HOME.
Thx in advance.
 
It's a combination of searching and wild guessing! Do so at your own risk and probably backup /usr/src/.svn/tmp:
rm -fr /usr/src/.svn/tmp
mkdir /usr/src/.svn/tmp
svn cleanup /usr/src
 
acheron said:
You shouln't use unionfs.
Click to expand...
Why? Could you explain? Thx. The reason for doing so was that I thought I can have multiple versions of the repository:
  • a genuine mirror under /src/13-CUR
  • multiple repositories (per "project") under my ~/Projects/FreeBSD/src/CUR
where my private repositories only need minimal space. Isn't that possible?
 
mount_unionfs()
Code: 
BUGS
     THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK)
     AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR OWN
     RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.  BATTERIES NOT INCLUDED.

     This code also needs an owner in order to be less dangerous - serious
     hackers can apply by sending mail to <freebsd-fs@FreeBSD.org> and
     announcing their intent to take it over.

     Without whiteout support from the file system backing the upper layer,
     there is no way that delete and rename operations on lower layer objects
     can be done.  EOPNOTSUPP is returned for this kind of operations as
     generated by VOP_WHITEOUT() along with any others which would make
     modifications to the lower layer, such as chmod(1).

     Running find(1) over a union tree has the side-effect of creating a tree
     of shadow directories in the upper layer.

     The current implementation does not support copying extended attributes
     for acl(9), mac(9), or so on to the upper layer.  Note that this may be a
     security issue.

     A shadow directory, which is one automatically created in the upper layer
     when it exists in the lower layer and does not exist in the upper layer,
     is always created with the superuser privilege.  However, a file copied
     from the lower layer in the same way is created by the user who accessed
     it.  Because of this, if the user is not the superuser, even in
     transparent mode the access mode bits in the copied file in the upper
     layer will not always be the same as ones in the lower layer.  This
     behavior should be fixed.
 
vigole said:
It's a combination of searching and wild guessing! Do so at your own risk and probably backup /usr/src/.svn/tmp:
rm -fr /usr/src/.svn/tmp
Click to expand...
I didn't have that directory, maybe it was deleted by svnup(1). So I did
vigole said:
mkdir /usr/src/.svn/tmp
svn cleanup /usr/src
Click to expand...
and now I have
Code: 
[... various A/U/G updates, + 3 Skipped: '<filename>' -- Node remains in conflict ]
Updated to revision 366385.
Summary of conflicts:
  Text conflicts: 4
  Tree conflicts: 1
  Skipped paths: 3
Searching tree conflict details for '.github' in repository:
Checking r366074... done
Tree conflict on '.github':
A new directory appeared during update to r366385; it was added by arichardson in r366074.
An unversioned directory was found in the working copy.

Subversion is not smart enough to resolve this tree conflict automatically!
See 'svn help resolve' for more information.

Select: (p) Postpone, (r) Mark as resolved, (h) Help, (q) Quit resolution:
Disclaimer: I'm not smart enough to solve that either... ;)
acheron Yes I was aware of that but choose to try it anyway... So I should use the port sysutils/fusefs-unionfs?
 
Right now I'm looking at base/head/.github => Directory revision: 366074 (of 366385)
Check svn status: svn status -u /usr/src
 
So I choose postpone on all conflicts and then
Code: 
root@t450s:/src/13-CUR # svnlite revert -R .
Reverted '.github'
Reverted '.github/workflows'
Reverted '.github/workflows/cross-bootstrap-tools.yml'
Reverted 'sys/kern/vfs_cache.c'
Reverted 'sys/dev/extres/syscon/syscon_generic.c'
Reverted 'tests/sys/fs/fusefs/write.cc'
Reverted 'lib/libc/gen/auxv.c'
root@t450s:/src/13-CUR # svnlite status -u .
?       *            share/man/man4/tcp_bbr.4
        *   366385   share/man/man4
?       *            tests/sys/posixshm/memfd_test.c
        *   366385   tests/sys/posixshm
?       *            stand/libsa/time.c
        *   366385   stand/libsa
        *   366385   sys/dev/pwm/pwm_backlight.c
?                    .svnversion
Status against revision: 366386
and now svnlite update updated one and gives the same 3 other conflicts, which I postponed again. The next svnlite update ran through without conflicts! Hurray! But svnlite status -u .
Code: 
?                    .svnversion
D     C     366386   share/man/man4/tcp_bbr.4
      >   local file unversioned, incoming file add upon update
D     C     366386   tests/sys/posixshm/memfd_test.c
      >   local file unversioned, incoming file add upon update
D     C     366386   stand/libsa/time.c
      >   local file unversioned, incoming file add upon update
Status against revision: 366386
Summary of conflicts:
  Tree conflicts: 3
Hm. What can I do about these? Note: /src/13-CUR is the genuine/mirrored repository.
 
acheron said:
mount_unionfs()
Code: 
BUGS
     THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK)
     AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM.  USE AT YOUR OWN
     RISK.  BEWARE OF DOG.  SLIPPERY WHEN WET.  BATTERIES NOT INCLUDED.

     This code also needs an owner in order to be less dangerous - serious
     hackers can apply by sending mail to <freebsd-fs@FreeBSD.org> and
     announcing their intent to take it over.

     Without whiteout support from the file system backing the upper layer,
     there is no way that delete and rename operations on lower layer objects
     can be done.  EOPNOTSUPP is returned for this kind of operations as
     generated by VOP_WHITEOUT() along with any others which would make
     modifications to the lower layer, such as chmod(1).

     Running find(1) over a union tree has the side-effect of creating a tree
     of shadow directories in the upper layer.

     The current implementation does not support copying extended attributes
     for acl(9), mac(9), or so on to the upper layer.  Note that this may be a
     security issue.

     A shadow directory, which is one automatically created in the upper layer
     when it exists in the lower layer and does not exist in the upper layer,
     is always created with the superuser privilege.  However, a file copied
     from the lower layer in the same way is created by the user who accessed
     it.  Because of this, if the user is not the superuser, even in
     transparent mode the access mode bits in the copied file in the upper
     layer will not always be the same as ones in the lower layer.  This
     behavior should be fixed.
Click to expand...

Ouch. I guess it's better to use one of the fuse implementations then.
 
mjollnir said:
So I choose postpone on all conflicts and then
Code: 
root@t450s:/src/13-CUR # svnlite revert -R .
Reverted '.github'
Reverted '.github/workflows'
Reverted '.github/workflows/cross-bootstrap-tools.yml'
Reverted 'sys/kern/vfs_cache.c'
Reverted 'sys/dev/extres/syscon/syscon_generic.c'
Reverted 'tests/sys/fs/fusefs/write.cc'
Reverted 'lib/libc/gen/auxv.c'
root@t450s:/src/13-CUR # svnlite status -u .
?       *            share/man/man4/tcp_bbr.4
        *   366385   share/man/man4
?       *            tests/sys/posixshm/memfd_test.c
        *   366385   tests/sys/posixshm
?       *            stand/libsa/time.c
        *   366385   stand/libsa
        *   366385   sys/dev/pwm/pwm_backlight.c
?                    .svnversion
Status against revision: 366386
and now svnlite update updated one and gives the same 3 other conflicts, which I postponed again. The next svnlite update ran through without conflicts! Hurray! But svnlite status -u .
Code: 
?                    .svnversion
D     C     366386   share/man/man4/tcp_bbr.4
      >   local file unversioned, incoming file add upon update
D     C     366386   tests/sys/posixshm/memfd_test.c
      >   local file unversioned, incoming file add upon update
D     C     366386   stand/libsa/time.c
      >   local file unversioned, incoming file add upon update
Status against revision: 366386
Summary of conflicts:
  Tree conflicts: 3
Hm. What can I do about these? Note: /src/13-CUR is the genuine/mirrored repository.
Click to expand...
Try this:
svn cleanup --remove-unversioned
 
Or you can delete these 3 files share/man/man4/tcp_bbr.4, tests/sys/posixshm/memfd_test.c and stand/libsa/time.c and then do svn up
 
OK I did svnlite cleanup --remove-unversioned which deleted the .svnversion. Then I did
Code: 
root@t450s:/src/13-CUR # svnlite cleanup --vacuum-pristines
root@t450s:/src/13-CUR # svnlite cleanup --remove-unversioned
root@t450s:/src/13-CUR # svnlite status -u .
D     C     366386   share/man/man4/tcp_bbr.4
      >   local file unversioned, incoming file add upon update
        *   366386   share/man/man4/netmap.4
        *   366386   tools/tools/netmap/pkt-gen.8
        *   366386   tools/tools/netmap/pkt-gen.c
        *   366386   sys/net/netmap_user.h
D     C     366386   tests/sys/posixshm/memfd_test.c
      >   local file unversioned, incoming file add upon update
D     C     366386   stand/libsa/time.c
      >   local file unversioned, incoming file add upon update
Status against revision: 366389
Summary of conflicts:
  Tree conflicts: 3
root@t450s:/src/13-CUR # svnlite update
Updating '.':
U    share/man/man4/netmap.4
U    tools/tools/netmap/pkt-gen.8
U    tools/tools/netmap/pkt-gen.c
U    sys/net/netmap_user.h
Updated to revision 366389.
root@t450s:/src/13-CUR # svnlite status -u .
D     C     366389   share/man/man4/tcp_bbr.4
      >   local file unversioned, incoming file add upon update
D     C     366389   tests/sys/posixshm/memfd_test.c
      >   local file unversioned, incoming file add upon update
D     C     366389   stand/libsa/time.c
      >   local file unversioned, incoming file add upon update
Status against revision: 366389
Summary of conflicts:
  Tree conflicts: 3
rm share/man/man4/tcp_bbr.4 tests/sys/posixshm/memfd_test.c stand/libsa/time.c
svnlite update
svnlite status -u .
Code: 
D     C     366389   share/man/man4/tcp_bbr.4
      >   local unversioned, incoming file add upon update
D     C     366389   tests/sys/posixshm/memfd_test.c
      >   local unversioned, incoming file add upon update
D     C     366389   stand/libsa/time.c
      >   local unversioned, incoming file add upon update
Status against revision: 366389
Summary of conflicts:
  Tree conflicts: 3
:mad: I'm out of options...
 
acheron said:
Post the result of:
Code: 
svn revert -R /usr/src
svn st | grep ^?
Click to expand...
svn revert -R /src/13-CUR
Code: 
Rückgängig gemacht: »/src/13-CUR/tests/sys/posixshm/memfd_test.c«
Rückgängig gemacht: »/src/13-CUR/share/man/man4/tcp_bbr.4«
Rückgängig gemacht: »/src/13-CUR/stand/libsa/time.c«
Translation: Rückgängig gemacht (ger) = Reverted (en)
root@t450s:~ # cd /src/13-CUR/
svn st | egrep '^?': <empty>
svnlite status -u .: only stars: * <filename> ...
svnlite update: Updating '.': ... A's & U's ...
svnlite status -u .: Status against revision: 366425 (OTT, nothing to complain) :cool:
 
  • Like
Reactions: a6h
You must log in or register to reply here.
Back
Top