hello, i've analysed svn commit command source code. attachment is the result.
the call stack of svn commit.
there are three position calling svn_io_open_unique_file3 , which function creates tmp file.
can you give some guide, which could create tmp file of working copy?
------------------
.........
Vanity...My favourite sin.
--<<The Devil's Advocate>>
------------------ 原始邮件 ------------------
发件人: "Johan Corveleyn";<jcorvel_at_gmail.com>;
发送时间: 2017年12月23日(星期六) 晚上11:31
收件人: "Keva-Slient"<356730059_at_qq.com>;
抄送: "Subversion"<users_at_subversion.apache.org>; "Bert Huijben"<rhuijben_at_apache.org>;
主题: Re: 回复： why my process open .svn/tmp/svn-XXXXXX file? and why aretmpfiles deleted? and why my process can't open the right file after tmpfiles deleted?
Op 23 dec. 2017 04:19 schreef "Keva-Slient" <356730059_at_qq.com>:
thank you for your patience. my English is very poor.
No problem, we'll try to communicate as best as we can :-). But please use "reply all" to keep the users-list in cc, so others can help out as well ...
1 It's still not clear what online-assist is really doing.
online-assist is our process. it opens db files stored in working copy. it keep db files open for read and write. file handle it has is same as db connection.
db file is managed by svn. stored in repository. not tmp file in .svn/tmp
2 What svn commands does it execute?
in client side. each repository only has one svn client user. the only one user of each repository only execute commit command.
in server side. we do svnadmin dump everyday to each repository
3 I don't understand why the deletes of the tmp files are a problem. Are you trying to keep those tmp files open?? That would be bad. You should NOT depend on those tmp files.
first of all, i don't keep tmp files open. i keep config file versioned by svn open( i keep config file saved by svn repository open). regular file saved in repository.
second, i keep the config file open. why has it been moved to tmp while i just only do commit command?(you had answered this)
third, why delete the tmp file while there is nothing different, nothing to merge, nothing conflict? can't svn move the tmp file back to repository? if svn could move tmp file back to where it was in repository while there is nothing to do with repository, tmp file will not be a problem.
4 Or is the problem that you're keeping the WORKING files open (as
opposed to the tmp files corresponding to them), and you want to keep
them open even while you're committing them? And subversion replaces
those files from underneath you, when you're committing them?
yes. we're keeping the WORKING files open.
why does committing make working file moved to tmp?can't svn copy working file to tmp and commit this tmp file? if svn can, it will not interrupt process. we only do committing for repository.
i think working file must be replaced only it needs merge when updating.
5 A possible reason for SVN to replace your working file while when
you're committing it, is keyword-expansion [1]. If you have such
keywords in your source file, and you have the "svn:keywords" property
set on it, SVN really has to change your file when you're committing.
i see you understand my question. i've explain a lot yet. LOL
we don't set svn:keywords on.and the deleted file are binary type.
6 But maybe that "replace file" codepath is executed even when there are
no keywords present and the svn:keywords property is not set... That
might be fixable.
yes. that's what we meet now.
7 OTOH, there might be other reasons why SVN needs to touch the file
when you're committing it (I haven't looked at the code).
thank you very much. i'm trying to debug svn commit to see when svn commit would create tmp file.
------------------
Okay, I think with your input above I understand the problem ('svn commit' moving your working file to .svn/tmp and replacing it with a new file after commit, even when svn:keywords is not set). Unfortunately I don't know enough about the internals of 'commit' to know why this would be happening or whether it can be avoided. Maybe Bert or someone else on the list can help more.
--
Johan
Received on 2017-12-29 06:54:54 CET
