svn: E000002: Невозможно создать символьную ссылку c после коммита, сбой очистки svn, как я могу восстановить? - PullRequest
0 голосов
/ 15 января 2020

Я добавил и передал две символические c ссылки на файлы, которые намеренно не зафиксированы, они относятся к учетным данным безопасности, которые не должны быть переданы в SVN.

# svn add submit.cer submit.pkey
A         submit.cer
A         submit.pkey

# svn commit submit.sh submit.cer submit.pkey -m "..."
Sending        submit.sh
Adding         submit.cer
Adding         submit.pkey
Transmitting file data ...
Committed revision 19433.
svn: E200000: Commit succeeded, but other errors follow:
svn: E000002: Error bumping revisions post-commit (details follow):
svn: E000002: Can't create symbolic link '/home/foobar/proj/.svn/tmp/svn-PvrkP3.tmp': No such file or directory

# svn status
svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted

# svn cleanup
svn: E000002: Can't create symbolic link '/home/foobar/proj/.svn/tmp/svn-qckOhQ.tmp': No such file or directory

Как восстановить из этого?

1 Ответ

0 голосов
/ 15 января 2020

Возможно, это не лучший ответ, но я решил свою проблему на данный момент, просто сняв капюшон и испачкав руки. Вот что я сделал:

Я пытался создать эти недостающие файлы, но он просто просит других:

# svn status
svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted
# touch /home/foobar/proj/.svn/tmp/svn-I03qQS.tmp
# svn status
svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted
# svn cleanup
svn: E000002: Can't create symbolic link '/home/foobar/proj/.svn/tmp/svn-lYugyl.tmp': No such file or directory
# touch /home/foobar/proj/.svn/tmp/svn-lYugyl.tmp
# svn cleanup
svn: E000002: Can't create symbolic link '/home/foobar/proj/.svn/tmp/svn-3exWGo.tmp': No such file or directory
# touch /home/foobar/proj/.svn/tmp/svn-3exWGo.tmp
# svn cleanup
svn: E000002: Can't create symbolic link '/home/foobar/proj/.svn/tmp/svn-TSibma.tmp': No such file or directory

Это старая версия SVN, версия 1.7.4 (r1295709) с 2012, но я знаю лучше, чем сейчас, пытаясь обновить.

Давайте посмотрим, что я могу сделать с w c .db

# sqlite3 wc.db .dump |egrep 'submit.(cer|pkey)'
INSERT INTO "NODES" VALUES(1,'submit.cer',0,'',1,'proj/submit.cer',19433,'normal',NULL,NULL,'file',X'2873766E3A7370656369616C2031202A29',NULL,'$sha1$115f82f76a709733e88d9f26a7a5f01a47953401',NULL,19433,1579098137216132,'foobar',NULL,NULL,X'2873766E3A77633A72615F6461763A76657273696F6E2D75726C203337202F69722F73766E2F2173766E2F7665722F31393433332F8888882F7375626D69742E63657229',NULL);
INSERT INTO "NODES" VALUES(1,'submit.pkey',0,'',1,'proj/submit.pkey',19433,'normal',NULL,NULL,'file',X'2873766E3A7370656369616C2031202A29',NULL,'$sha1$99747e06d352668bf515639d0a6ec3dbf86cc1ff',NULL,19433,1579098137216132,'foobar',NULL,NULL,X'2873766E3A77633A72615F6461763A76657273696F6E2D75726C203338202F69722F73766E2F2173766E2F7665722F31393433332F68888882F7375626D69742E706B657929',NULL);

Так что же это?

# sqlite3 wc.db '.schema NODES'
CREATE TABLE NODES (
   wc_id  INTEGER NOT NULL REFERENCES WCROOT (id),
   local_relpath  TEXT NOT NULL,
   op_depth INTEGER NOT NULL,
   parent_relpath  TEXT,
   repos_id  INTEGER REFERENCES REPOSITORY (id),
   repos_path  TEXT,
   revision  INTEGER,
   presence  TEXT NOT NULL, 
   moved_here  INTEGER,
   moved_to  TEXT,
   kind  TEXT NOT NULL,
   properties  BLOB,
   depth  TEXT,
   checksum  TEXT REFERENCES PRISTINE (checksum),
   symlink_target  TEXT,
   changed_revision  INTEGER,
   changed_date      INTEGER,
   changed_author    TEXT,
   translated_size  INTEGER,
   last_mod_time  INTEGER,
   dav_cache  BLOB,
   file_external  TEXT,
   PRIMARY KEY (wc_id, local_relpath, op_depth)
);

Интересные вещи: symlink_target

sqlite3 wc.db "SELECT symlink_target,NULL,'' FROM NODES WHERE local_relpath = 'submit.cer'"
||

, так что цель символической ссылки - NULL, это вполне может быть то, что ее отбрасывает. К сожалению, у меня нет случая, чтобы я мог проверить это:

sqlite3 wc.db "SELECT local_relpath,symlink_target FROM NODES WHERE symlink_target IS NOT NULL"

ничего.

Итак, что, если я просто удалю эти два УЗЛА?

# sqlite3 wc.db "CREATE TABLE BADNODES AS SELECT * FROM NODES WHERE local_relpath IN ('submit.cer', 'submit.pkey')"
# sqlite3 wc.db "SELECT * FROM BADNODES"
1|submit.cer|0||1|proj/submit.cer|19433|normal|||file|(svn:special 1 *)||$sha1$a15f82f76a709733e88d9f26a7a5f01a47953401||19433|1579098137216132|foobar|||(svn:wc:ra_dav:version-url 37 /ir/svn/!svn/ver/19433/proj/submit.cer)|
1|submit.pkey|0||1|proj/submit.pkey|19433|normal|||file|(svn:special 1 *)||$sha1$a9747e06d352668bf515639d0a6ec3dbf86cc1ff||19433|1579098137216132|foobar|||(svn:wc:ra_dav:version-url 38 /ir/svn/!svn/ver/19433/proj/submit.pkey)|
# sqlite3 wc.db "DELETE FROM NODES WHERE local_relpath IN ('submit.cer', 'submit.pkey')"
# cd ..
# svn cleanup
svn: E155010: The node '/home/foobar/submit.cer' was not found.

Так это все еще есть что-то о submit.cer сейчас. А откуда? Нет в базе.

# sqlite3 wc.db .dump |fgrep submit.cer |fgrep -v BADNODES
# find . -name 'submit.cer'
# fgrep -Rl submit.cer .
./pristine/2a/2a5fe860af1b54b5b63978176e345b2d6cf57e01.svn-base
./wc.db

ага, так что это первозданная вещь. Но это красная сельдь, этот первозданный файл - просто еще один файл submit. sh, который я зафиксировал и который содержит submit.cer в его тексте, так что svn ничего не узнает. Откуда svn cleanup даже знает, что должно быть что-то с именем submit.cer?

Это может быть получено из этого столбца со следующим значением:

(svn:wc:ra_dav:version-url 38 /ir/svn/!svn/ver/19433/proj/submit.cer)

из столбца

dav_cache  BLOB,

со значением:

X'2873766E3A77633A72615F6461763A76657273696F6E2D75726C203337202F69722F73766E2F2173766E2F7665722F31393433332F8888882F7375626D69742E63657229'

, поэтому мне лучше искать все столбцы BLOB, упоминают ли они файл submit.cer. И это не очень сложно,

# echo "submit.cer" |od -t x1
0000000 73 75 62 6d 69 74 2e 63 65 72 0a
0000013

, поэтому я могу искать:

# sqlite3 wc.db .dump |fgrep 7375626D69742E636572
INSERT INTO "WORK_QUEUE" VALUES(209,X'2866696C652D636F6D6D6974207375626D69742E636572203120302031203029');
INSERT INTO "BADNODES" VALUES(1,'submit.cer',0,'',1,'proj/submit.cer',19433,'normal',NULL,NULL,'file',X'2873766E3A7370656369616C2031202A29',NULL,'$sha1$115f82f76a709733e88d9f26a7a5f01a47953401',NULL,19433,1579098137216132,'gschadow',NULL,NULL,X'2873766E3A77633A72615F6461763A76657273696F6E2D75726C203337202F69722F73766E2F2173766E2F7665722F31393433332F8888882F7375626D69742E63657229',NULL);

так что я go, это WORK_QUEUE!

# sqlite3 wc.db '.schema WORK_QUEUE'
CREATE TABLE WORK_QUEUE (
   id  INTEGER PRIMARY KEY AUTOINCREMENT,
   work  BLOB NOT NULL
);

# sqlite3 wc.db 'select * from WORK_QUEUE'
209|(file-commit submit.cer 1 0 1 0)
210|(file-commit submit.pkey 1 0 1 0)

отлично! Так что, если я просто уберу их из WORK_QUEUE?

# sqlite3 wc.db 'CREATE TABLE BAD_WORK_QUEUE AS SELECT * FROM WORK_QUEUE'
# sqlite3 wc.db 'DELETE FROM WORK_QUEUE'

и теперь tada!

# cd ..
# svn cleanup
# svn status |fgrep submit
?       submit.cer
?       submit.pkey

это выглядит действительно многообещающе, как если бы плохие ссылки никогда не передавались? Должны ли мы попробовать? Упс:

# svn update
Updating '.':
   C submit.pkey
   C submit.cer
Updated to revision 19433.
Summary of conflicts:
  Tree conflicts: 2

, но затем волшебным образом:

# svn update
Updating '.':
At revision 19433.

# svn status |fgrep submit
D     C submit.cer
D     C submit.pkey

Это очень аккуратно! Таким образом, я могу выжить в своей работе дальше, просто больше не буду фиксировать эти символические ссылки.

На данный момент урок таков: никогда не фиксируйте символическую ссылку без фиксации цели!?

...