Re: AW: How to find out the rev number where a file was deleted?
[ sorry if I'm repeating; haven't read the whole thread ] Johan Corveleyn wrote on Sun, Nov 28, 2010 at 10:05:15 +0100: FWIW, you do have a point, Andrey (and others), that this is a valid use case (finding the rev in which a file was deleted) which isn't well supported by svn currently. I think the svn devs are very much aware of this, but it just isn't there yet. See also this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3627 - FS API support for oldest-to-youngest history traversal It literally mentions this use case as one of the high-level user needs: - allowing 'svn log' to fully traverse the entire history of a given versioned object, both for completeness' sake and to facilitate (for example) resurrection of deleted items from their most-recently-existing forms. Unfortunately, according to the current plans, it might be a while before this is implemented. On the roadmap, it is listed as being dependent on FS-NG (Flexible Repository Storage), on the list of most wanted features: http://subversion.apache.org/roadmap.html#features-most-wanted. Just to clarify, this doesn't mean we don't like this feature; it means a non-trivial bit of work is needed to implement it, because this question is not easily answerable given the current state/design of the backends. There are two related questions here: * Given p...@rn which exists, what is the largest rM such that p...@ri and p...@rn are the same node (no adds/replaces/deletes have occured in or above PATH) for all N≤I≤M? * What are all the (path,revision) objects that are the same line of history as a given p...@rn? In other words, what are all the places p...@rn has been copied to, and all the revisions where those copies were touched?
Re: AW: How to find out the rev number where a file was deleted?
On Sun, Nov 28, 2010 at 01:27:28PM +0200, Daniel Shahaf wrote: [ sorry if I'm repeating; haven't read the whole thread ] Johan Corveleyn wrote on Sun, Nov 28, 2010 at 10:05:15 +0100: FWIW, you do have a point, Andrey (and others), that this is a valid use case (finding the rev in which a file was deleted) which isn't well supported by svn currently. I think the svn devs are very much aware of this, but it just isn't there yet. See also this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3627 - FS API support for oldest-to-youngest history traversal It literally mentions this use case as one of the high-level user needs: - allowing 'svn log' to fully traverse the entire history of a given versioned object, both for completeness' sake and to facilitate (for example) resurrection of deleted items from their most-recently-existing forms. Unfortunately, according to the current plans, it might be a while before this is implemented. On the roadmap, it is listed as being dependent on FS-NG (Flexible Repository Storage), on the list of most wanted features: http://subversion.apache.org/roadmap.html#features-most-wanted. Just to clarify, this doesn't mean we don't like this feature; it means a non-trivial bit of work is needed to implement it, because this question is not easily answerable given the current state/design of the backends. There are two related questions here: * Given p...@rn which exists, what is the largest rM such that p...@ri and p...@rn are the same node (no adds/replaces/deletes have occured in or above PATH) for all N≤I≤M? * What are all the (path,revision) objects that are the same line of history as a given p...@rn? In other words, what are all the places p...@rn has been copied to, and all the revisions where those copies were touched? Of course, these questions can be answered by a human or a script if given some time to crawl through the output of svn log. E.g. the trumerge script does this: http://trumerge.open.collab.net/ The real problem is that we want to be able to answer these questions very fast, and some design aspects work against this. For instance, FSFS by design does not allow modifying old revisions. So where do we store the copy-to information for a given p...@n? The best idea we've had so far was using an sqlite database. But that's really a hack around a design that doesn't support all the features we want. Stefan
Re: AW: How to find out the rev number where a file was deleted?
On 11/28/10 12:28 AM, Andrey Repin wrote: It doesn't track the future of a file, it tracks the history. Start with a peg revision Wat? It start with HEAD irrelevant to what PEG revision we've specified. And immediately spitting no such file, although the file is 100% there. Yes, if you ask it for HEAD in your range, it has to start there because history only goes backwards. Or it will try to and fail. [C:\]$svn log -v -r 0:HEAD -- http://svn.darkdragon/repos/t...@2 svn: '/repos/!svn/bc/35/test' path not found But you are asking it to track the future of that file to a place it doesn't exist. I beg to differ. I'm asking to 1. Pick the file (directory) /test at revision 2 2. Track it's changes history from revision 0 to HEAD. But, because subversion tracks a file's history, not it's future even if you think you are asking it to start with rev 0 and go forward, in fact it can only start with the last rev and work backwards. 3. I'm fully aware that the directory does not exist in HEAD, neither I ask Subversion to look there in first place. (literal meaning of first place) You have asked it to pick the version of /test that existed at revision 2, then get the history of that item in HEAD back to rev 0 and print it out backwards. Or at least that's the only way it can attempt to do what you asked. 4. Quite (un)surprisingly, my intent is to actually find revision, in which the destruction was made. Because, quite (un)surprisingly, I don't know that. I'd like to be able to see the future too - but unfortunately, neither subversion nor I can do that. Nah, it could just obey to @PEG rule. Everything will be simpler. Unless there's absolutely no other way to track the file from @PEG, which i doubt, since you DO can access the file by @PEG, as well as navigate back in time easier, than forward. It does obey @peg, and it can navigate as far as that item existed. If you give it a range where that item exists at the latest rev it will show you the log of its history. If you give it a range where the item doesn't exist it will tell you it doesn't exist because it can only work by finding the highest rev in the range and following history. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
Stefan Sperling wrote on Sun, Nov 28, 2010 at 16:48:30 +0100: The real problem is that we want to be able to answer these questions very fast, and some design aspects work against this. For instance, FSFS by design does not allow modifying old revisions. So where do we store the copy-to information for a given p...@n? copy-to information is immutable (never changes once created), so we could add another hierarchy (parallel to revs/ and revprops/) in which to store that information. Any 'cp f...@n bar' operation would need to create/append a file in that hierarchy. Open question: how to organize $new_hierarchy/16/16384/** to make it efficiently appendable and queryable (and for what queries? Iterate all copied-to places is one). Makes sense? The best idea we've had so far was using an sqlite database. But that's really a hack around a design that doesn't support all the features we want. Stefan
Re: AW: How to find out the rev number where a file was deleted?
On Sun, Nov 28, 2010 at 6:35 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Stefan Sperling wrote on Sun, Nov 28, 2010 at 16:48:30 +0100: The real problem is that we want to be able to answer these questions very fast, and some design aspects work against this. For instance, FSFS by design does not allow modifying old revisions. So where do we store the copy-to information for a given p...@n? copy-to information is immutable (never changes once created), so we could add another hierarchy (parallel to revs/ and revprops/) in which to store that information. Any 'cp f...@n bar' operation would need to create/append a file in that hierarchy. Open question: how to organize $new_hierarchy/16/16384/** to make it efficiently appendable and queryable (and for what queries? Iterate all copied-to places is one). Makes sense? I'm not sure. But there is another alternative: while we wait for FS-NG (or another solution like you propose), one could implement the slow algorithm within the current design. Just automating what a user (or script) currently does when looking for this information, i.e. a binary search. Of course it would be slow, but it would certainly already provide value. At the very least, it saves users a lot of time searching FAQ's and list archives, wondering why this doesn't work, understanding the design limitations, and then finally implementing their own script or doing a one-time manual search. Then, when FS-NG arrives, or someone comes up with a way to index this information, it can be optimized. I don't know if there would be fundamental problems with that, apart from the fact that someone still needs to implement it of course ... Cheers, -- Johan
Re: AW: How to find out the rev number where a file was deleted?
Johan Corveleyn wrote on Sun, Nov 28, 2010 at 21:20:28 +0100: On Sun, Nov 28, 2010 at 6:35 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Stefan Sperling wrote on Sun, Nov 28, 2010 at 16:48:30 +0100: The real problem is that we want to be able to answer these questions very fast, and some design aspects work against this. For instance, FSFS by design does not allow modifying old revisions. So where do we store the copy-to information for a given p...@n? copy-to information is immutable (never changes once created), so we could add another hierarchy (parallel to revs/ and revprops/) in which to store that information. Any 'cp f...@n bar' operation would need to create/append a file in that hierarchy. Open question: how to organize $new_hierarchy/16/16384/** to make it efficiently appendable and queryable (and for what queries? Iterate all copied-to places is one). Makes sense? I'm not sure. But there is another alternative: while we wait for FS-NG (or another solution like you propose), one could implement the slow algorithm within the current design. Are you advocating to implement it in the core (as an svn_fs_* API) or as a third-party script? The latter is certainly fine, but regarding the former I don't see the point of adding an API that cannot be implemented efficiently at this time. Just automating what a user (or script) currently does when looking for this information, i.e. a binary search. Of course it would be slow, but it would certainly already provide value. At the very least, it saves users a lot of time searching FAQ's and list archives, wondering why this doesn't work, understanding the design limitations, and then finally implementing their own script or doing a one-time manual search. Then, when FS-NG arrives, or someone comes up with a way to index this information, it can be optimized. I don't know if there would be fundamental problems with that, apart from the fact that someone still needs to implement it of course ... Cheers, -- Johan
Re: AW: How to find out the rev number where a file was deleted?
On Sun, Nov 28, 2010 at 7:59 AM, Andrey Repin anrdae...@freemail.ruwrote: Greetings, Les Mikesell! thanks for having responded. Can I file a feature request for that in the issue tracker, what do you think? @Ryan: Of course with a peg rev I can log that single rev. But the rev number of that rev is that what we are looking for! To find out this rev number, we want to use an earlier peg rev where we know that the file still existed and want to add -r1:head as operative revs to see all revs including the rev where the file was deleted. The deletion should show in an 'svn log -v' of the directory where the file was deleted. That directory was deleted as well. As well, at unknown revision. Multiple times. The question is not that we can work around the issue, the question is, why Subversion can't do this for us? I can add my own case to this list. http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065dsMessageId=1850347 I can understand that it's not easy to track deletes/copies forward, but tracking history from creation time to deletion(renamind implies deletion) time should be possible IMO. And this should be possible without user's guesswork. It's fairly simple to find correct revision range in repository with 40 commits. In repository with 40,000 commits things became a bit scary Have you tried a combination of 'log -v' and grep? IMHO, that would be the quickest to implement, and simplest to achieve. Cheers, Daniel B.
Svn merge crashed
see log file Process info: Cmd line: svn merge [myURL] Version: 1.6.12 (SlikSvn/1.6.12) WIN32, compiled Jun 22 2010, 20:45:23 Platform: Windows OS version 5.1 build 2600 Service Pack 3 Exception: ACCESS_VIOLATION Registers: eax=0001 ebx=00e795c8 ecx=00495cb9 edx=01a76a00 esi= edi=0008 eip=00356ab6 esp=0012f9dc ebp=00356a87 efl=00010202 cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= Stacktrace: #1 0x00356ab6 in apr_palloc () #2 0x07788d57 in (unknown function) Loaded modules: 0x0040 D:\Programmierung\SlikSvn\bin\svn.exe (1.6.12.38263, 163840 bytes) 0x7c91 C:\WINDOWS\system32\ntdll.dll (5.1.2600.5755, 757760 bytes) 0x7c80 C:\WINDOWS\system32\kernel32.dll (5.1.2600.5781, 1081344 bytes) 0x6eec D:\Programmierung\SlikSvn\bin\SlikSvn-libintl-win32.dll (0.0.0.0, 49152 bytes) 0x7852 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_d495ac4e\msvcr90.dll (9.0.30729.4148, 667648 bytes) 0x0035 D:\Programmierung\SlikSvn\bin\SlikSvn-libapr-1.dll (1.3.12.0, 131072 bytes) 0x71a1 C:\WINDOWS\system32\ws2_32.dll (5.1.2600.5512, 94208 bytes) 0x77da C:\WINDOWS\system32\advapi32.dll (5.1.2600.5755, 696320 bytes) 0x77e5 C:\WINDOWS\system32\rpcrt4.dll (5.1.2600.6022, 602112 bytes) 0x77fc C:\WINDOWS\system32\secur32.dll (5.1.2600.5834, 69632 bytes) 0x77be C:\WINDOWS\system32\msvcrt.dll (7.0.2600.5512, 360448 bytes) 0x71a0 C:\WINDOWS\system32\ws2help.dll (5.1.2600.5512, 32768 bytes) 0x719b C:\WINDOWS\system32\mswsock.dll (5.1.2600.5625, 262144 bytes) 0x1000 D:\Programmierung\SlikSvn\bin\SlikSvn-svn_client-1.dll (1.6.12.38263, 184320 bytes) 0x6ee6 D:\Programmierung\SlikSvn\bin\SlikSvn-libaprutil-1.dll (1.3.9.0, 176128 bytes) 0x003a D:\Programmierung\SlikSvn\bin\SlikSvn-svn_delta-1.dll (1.6.12.38263, 90112 bytes) 0x0043 D:\Programmierung\SlikSvn\bin\SlikSvn-svn_subr-1.dll (1.6.12.38263, 585728 bytes) 0x7e67 C:\WINDOWS\system32\shell32.dll (6.0.2900.6018, 8523776 bytes) 0x77ef C:\WINDOWS\system32\gdi32.dll (5.1.2600.5698, 299008 bytes) 0x7e36 C:\WINDOWS\system32\user32.dll (5.1.2600.5512, 593920 bytes) 0x77f4 C:\WINDOWS\system32\shlwapi.dll (6.0.2900.5912, 483328 bytes) 0x774b C:\WINDOWS\system32\ole32.dll (5.1.2600.6010, 1302528 bytes) 0x77a5 C:\WINDOWS\system32\crypt32.dll (5.131.2600.5512, 614400 bytes) 0x77af C:\WINDOWS\system32\msasn1.dll (5.1.2600.5875, 73728 bytes) 0x003e D:\Programmierung\SlikSvn\bin\SlikSvn-svn_diff-1.dll (1.6.12.38263, 53248 bytes) 0x004c D:\Programmierung\SlikSvn\bin\SlikSvn-svn_ra-1.dll (1.6.12.38263, 430080 bytes) 0x0054 D:\Programmierung\SlikSvn\bin\SlikSvn-svn_repos-1.dll (1.6.12.38263, 135168 bytes) 0x0058 D:\Programmierung\SlikSvn\bin\SlikSvn-svn_fs-1.dll (1.6.12.38263, 208896 bytes) 0x1300 D:\Programmierung\SlikSvn\bin\SlikSvn-DB44-20-win32.dll (4.0.4.20, 757760 bytes) 0x7848 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_d495ac4e\msvcp90.dll (9.0.30729.4148, 581632 bytes) 0x005e D:\Programmierung\SlikSvn\bin\SlikSvn-LIBEAY32.dll (1.0.0.1, 1200128 bytes) 0x0072 D:\Programmierung\SlikSvn\bin\SlikSvn-SSLEAY32.dll (1.0.0.1, 249856 bytes) 0x0077 D:\Programmierung\SlikSvn\bin\SlikSvn-Sasl21-23-win32.dll (2.1.23.0, 139264 bytes) 0x007b D:\Programmierung\SlikSvn\bin\SlikSvn-svn_wc-1.dll (1.6.12.38263, 192512 bytes) 0x7633 C:\WINDOWS\system32\imm32.dll (5.1.2600.5512, 118784 bytes) 0x773a C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll (6.0.2900.6028, 1060864 bytes) 0x5d45 C:\WINDOWS\system32\comctl32.dll (5.82.2900.6028, 630784 bytes) 0x71f1 C:\WINDOWS\system32\security.dll (5.1.2600.5512, 16384 bytes) 0x77c4 C:\WINDOWS\system32\msv1_0.dll (5.1.2600.5876, 151552 bytes) 0x7674 C:\WINDOWS\system32\cryptdll.dll (5.1.2600.5512, 49152 bytes) 0x76d2 C:\WINDOWS\system32\iphlpapi.dll (5.1.2600.5512, 102400 bytes) 0x6800 C:\WINDOWS\system32\rsaenh.dll (5.1.2600.5507, 221184 bytes) 0x76ee C:\WINDOWS\system32\dnsapi.dll (5.1.2600.5625, 159744 bytes) 0x76f8 C:\WINDOWS\system32\rasadhlp.dll (5.1.2600.5512, 24576 bytes) 0x6671 C:\WINDOWS\system32\hnetcfg.dll (5.1.2600.5512, 364544 bytes) 0x719f C:\WINDOWS\system32\wshtcpip.dll (5.1.2600.5512, 32768 bytes) 0x5b0f C:\WINDOWS\system32\uxtheme.dll (6.0.2900.5512, 229376 bytes) 0x7662 C:\WINDOWS\system32\userenv.dll (5.1.2600.5512, 745472 bytes) 0x77bd C:\WINDOWS\system32\version.dll (5.1.2600.5512, 32768 bytes) 0x597d C:\WINDOWS\system32\netapi32.dll (5.1.2600.5694, 348160 bytes) 0x01fd C:\WINDOWS\system32\xpsp2res.dll (5.1.2600.5512, 2985984 bytes) 0x7658 C:\WINDOWS\system32\cryptnet.dll (5.131.2600.5512, 77824 bytes) 0x76bb C:\WINDOWS\system32\psapi.dll (5.1.2600.5512, 45056 bytes) 0x7224 C:\WINDOWS\system32\sensapi.dll
