RE: AW: How to find out the rev number where a file was deleted?
-Original Message- From: Les Mikesell On 11/30/2010 12:04 PM, Ludwig, Michael wrote: True, but many humans tend to attach meaning to names, to remember them, and to refer to them. But when humans use names they have to understand their non-unique nature or face surprises. If there was a Les Mikesell before 1949, it wasn't me. If there are others now, they aren't me either. Subversion represents a matrix of paths and time; different names come and go over time and very often many different names refer to the same thing and the same name may to different things at different times. Exactly. Most humans do understand. For instance, I'm aware that in the place where I live there may be 20 or 50 people with exactly the same name. I understood the non-uniqueness of names back in elementary school. A forteriori, developers do understand. It doesn't have this functionality right now. You'd have to parse the output of log -v, yes. It's onerous on both the server and the human. Saying you don't like to parse the answer isn't the same as saying it doesn't have the functionality. It provides data that you then have to scan, but it doesn't support the lookup operation I want. There are lots of other places I would consider more important than making it easy to find something you deleted on purpose. Sure, there might be more important things. And if you did have the name lookup you want, you still have to deal with the issue that in every rev where the name is found it may be some different object. It is not an issue, Andrey and I mentioned that repeatedly. The revision disambiguates the name and provides identity. Best, Michael
Re: AW: How to find out the rev number where a file was deleted?
On 12/1/2010 6:40 AM, Ludwig, Michael wrote: And if you did have the name lookup you want, you still have to deal with the issue that in every rev where the name is found it may be some different object. It is not an issue, Andrey and I mentioned that repeatedly. I think the functionality he wants is different. The revision disambiguates the name and provides identity. It seems like you are asking for what you would get if you collate the output of: svn ls -r? URL where you cycle the ? through all the revisions. That is, you want every instance where the name appears regardless of the objects referenced by that name. I think Andrey wants something more like: svn log -r0:? u...@peg where the ? is the highest rev where the same object was present at that path. Or at least to find the value of that highest rev. But for me, the question I would want to be able to answer would more likely be where else was this copied? as in what release tags include this file or its descendants? or what is its new name after a move in a future rev? But we all agree that there are things you might want that you can't do easily. The developers here all use an issue tracking system with tickets to discuss the changes being done and always include the ticket number in a certain format in the commit message for every commit - in fact we just added a pre-commit hook to enforce that. And I think the svn revision that completes/closes an issue goes back to the ticket. This doesn't exactly address tracking changes to individual files and objects, but at a higher level it connects the purpose of a change with the work itself and lets you use a better tool to handle the related context, making it less likely that you would need a brute-force search for lost items. -- Les Mikesell lesmikes...@gmail.com
RE: AW: How to find out the rev number where a file was deleted?
From: Les Mikesell [mailto:lesmikes...@gmail.com] On 12/1/2010 6:40 AM, Ludwig, Michael wrote: And if you did have the name lookup you want, you still have to deal with the issue that in every rev where the name is found it may be some different object. It is not an issue, Andrey and I mentioned that repeatedly. I think the functionality he wants is different. It is. But there was overlap in what we said. The revision disambiguates the name and provides identity. It seems like you are asking for what you would get if you collate the output of: svn ls -r? URL where you cycle the ? through all the revisions. That is, you want every instance where the name appears regardless of the objects referenced by that name. No, but not entirely dissimilar. I gave an example a couple of messages ago. Best, Michael
RE: AW: How to find out the rev number where a file was deleted?
-Original Message- From: Les Mikesell On 11/29/2010 11:45 AM, Ludwig, Michael wrote: I can see that from the peg rev point of view, HEAD is the future. But I think we can also agree that from the SVN user's perspective, every single existing rev including HEAD is in the past. Yes, but from the perspective of getting history where you can only go backwards, you have to specify the right starting point, and a rev where the thing doesn't exist isn't the right place. Certainly. Just imagine you weren't required to specify a revision: svn show svn://server.dev/eins/zwei/drei/vier.txt seq node-id revision status 1 1bca34933 A 1 1bca34975 M 1 1bca34976 M 1 1bca349 111 M 1 1bca349 188 D 2 4941b20 1099 A 2 4941b20 1101 M 2 4941b20 1108 M 2 4941b20 1831 D 3 6e6cdff 18004 A 3 6e6cdff 18014 M The node ID would identify the versioned object. (I don't know anything about what the node ID might look like; the example is just a wild guess.) This sketch certainly has flaws, but is it an unreasonable proposal? Users might find it useful. Yes, there could be several items - several revision ranges - in the index, pointing to several unrelated objects. But is it a big problem? Yes, if you are in the habit of deleting things and adding them back, then wanting one of the deleted versions. You'd read it from the list and identify it by revision. No changes to existing behaviour and functionality. In database speak, we'd indeed have a compound key for *uniquely* identifying an object, with the first part of that compound key being the URL, and the second part the revision. But if we don't know the revision, we simply use the URL alone and receive a list of all the items ever to have appeared at that URL. Which ones we're interested in is then a matter of human decision; but gone is the tedium (or wasteful scanning) of establishing the list in the first place. That's a reasonable thing to want, but perhaps not reasonable for the server to deliver. Would you expect your database to find things for you if you renamed or deleted the table holding them? I wouldn't. But if I had a trigger to log changes made to a table to a log table I'd expect the system to know the table history. That's maybe a bit more aligned with what I might expect from a version control system. A thing with the same name added later as a replacement may have nothing in common with the item you want. I'm not sure what the right test for this would be other than asking for a log with a rev range and a peg rev to anchor it to one specific version. Give me a listing of the things and either require me to specify which one I want or show them all in full detail, depending on the circumstances. In the special case where there is only one item in the list, no further precision is needed. It's a big order to make that happen through a client-server connection that has no such existing concept and no server side hints to do it efficiently. I agree the server side needs to have the URL index to do it efficiently. Given that index, however, it shouldn't be difficult. I wouldn't redesign the existing set of commands, just provide one in addition that provides the history of a URL. Best, Michael
Re: AW: How to find out the rev number where a file was deleted?
On 11/30/10 5:21 AM, Ludwig, Michael wrote: I can see that from the peg rev point of view, HEAD is the future. But I think we can also agree that from the SVN user's perspective, every single existing rev including HEAD is in the past. Yes, but from the perspective of getting history where you can only go backwards, you have to specify the right starting point, and a rev where the thing doesn't exist isn't the right place. Certainly. Just imagine you weren't required to specify a revision: svn show svn://server.dev/eins/zwei/drei/vier.txt seq node-id revision status 1 1bca34933 A 1 1bca34975 M 1 1bca34976 M 1 1bca349 111 M 1 1bca349 188 D 2 4941b20 1099 A 2 4941b20 1101 M 2 4941b20 1108 M 2 4941b20 1831 D 3 6e6cdff 18004 A 3 6e6cdff 18014 M The node ID would identify the versioned object. (I don't know anything about what the node ID might look like; the example is just a wild guess.) This sketch certainly has flaws, but is it an unreasonable proposal? Users might find it useful. But the name has nothing to do with the versioning of the object. Names appear in the directory containing it. The object itself might have a different name every revision if the modifications are moves. Or the same name might be a different object with deletes followed by adds or copies to the name in question. Subversion only tracks the object itself using the name to identify a starting point. But you can see the names come and go in the history of the directories containing them. Yes, there could be several items - several revision ranges - in the index, pointing to several unrelated objects. But is it a big problem? Yes, if you are in the habit of deleting things and adding them back, then wanting one of the deleted versions. You'd read it from the list and identify it by revision. No changes to existing behaviour and functionality. Where does the client/server protocol have such functionality now? I think it is only in showing a log -v of the directory containing the name. I wouldn't. But if I had a trigger to log changes made to a table to a log table I'd expect the system to know the table history. That's maybe a bit more aligned with what I might expect from a version control system. You have that in the versioning of the directory where the name appears. It's a big order to make that happen through a client-server connection that has no such existing concept and no server side hints to do it efficiently. I agree the server side needs to have the URL index to do it efficiently. Given that index, however, it shouldn't be difficult. I wouldn't redesign the existing set of commands, just provide one in addition that provides the history of a URL. That already exists. A 'log -v' from the top of the repo will show all deletes and adds ever done. The output isn't convenient to feed to grep, etc., though. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
On 11/30/10 7:35 AM, Andrey Repin wrote: Binary search on the 0 to HEAD revision range is a possibility, but it's also a rather wasteful workaround. Fisheye (a commercial product) does a brute-force extract/index of all the filenames and content in all revs in a repo for quick searches. I'm not sure if there is any equivalent open source program but this is probably the right answer for anyone who needs to do that frequently. Sorry, do you mean that we have to pay to cover the lack of functionality in Subversion? And it should remain this way? Yes, I would not expect fast indexed full-text searches across names and content to ever be a part of the version control system itself. But the functionality to find filename changes is there - just 'log -v' from the top. There's a big problem here - whether a URL exists or not usually isn't the right answer for things that have been deleted and replaced by something else of the same name. I strongly suspect that Ludwig had in mind that Subversion could track revisions in which file has been changed in either way. Then no way you could confuse between different files with same URL. It does track that, but I don't think there is a convenient way to ask for it. Or for the server itself to find it efficiently. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! Binary search on the 0 to HEAD revision range is a possibility, but it's also a rather wasteful workaround. Fisheye (a commercial product) does a brute-force extract/index of all the filenames and content in all revs in a repo for quick searches. I'm not sure if there is any equivalent open source program but this is probably the right answer for anyone who needs to do that frequently. Sorry, do you mean that we have to pay to cover the lack of functionality in Subversion? And it should remain this way? Yes, I would not expect fast indexed full-text searches across names and content to ever be a part of the version control system itself. But the functionality to find filename changes is there - just 'log -v' from the top. Where you see a reference to full-text search in my quote? I have intentionally omit that part of your reply. There's a big problem here - whether a URL exists or not usually isn't the right answer for things that have been deleted and replaced by something else of the same name. I strongly suspect that Ludwig had in mind that Subversion could track revisions in which file has been changed in either way. Then no way you could confuse between different files with same URL. It does track that, but I don't think there is a convenient way to ask for it. Or for the server itself to find it efficiently. It only track it back into the past. There's no sane way to track it forward currently. I see some complications in implementation of this ability, mainly in the controversial way it should work (i.e. alter multiple previous revisions to embed the forward tracking links, or to maintain a parallel base for them). -- WBR, Andrey Repin (anrdae...@freemail.ru) 30.11.2010, 21:10 Sorry for my terrible english...
Re: AW: How to find out the rev number where a file was deleted?
On 11/30/2010 12:04 PM, Ludwig, Michael wrote: But the name has nothing to do with the versioning of the object. True, but many humans tend to attach meaning to names, to remember them, and to refer to them. For example, names often appear in the contents of other files. They just have a tendency of cropping up here and there. People might find it useful if Subversion had better support for this. But when humans use names they have to understand their non-unique nature or face surprises. If there was a Les Mikesell before 1949, it wasn't me. If there are others now, they aren't me either. Subversion represents a matrix of paths and time; different names come and go over time and very often many different names refer to the same thing and the same name may to different things at different times. Where does the client/server protocol have such functionality now? I think it is only in showing a log -v of the directory containing the name. It doesn't have this functionality right now. You'd have to parse the output of log -v, yes. It's onerous on both the server and the human. Saying you don't like to parse the answer isn't the same as saying it doesn't have the functionality. That already exists. A 'log -v' from the top of the repo will show all deletes and adds ever done. The output isn't convenient to feed to grep, etc., though. It would work, somehow. I'm aware of that. I'm just imagining a more convenient feature that also performs better. A lookup instead of a scan. There are lots of other places I would consider more important than making it easy to find something you deleted on purpose. A handy way to track where something went when you later copied to a tag might be something people would be more likely to want to know frequently - but again, the answer might be large and hard to parse because there's no particular limit to the number of copies that could have been made. And if you did have the name lookup you want, you still have to deal with the issue that in every rev where the name is found it may be some different object. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
On 11/30/2010 12:19 PM, Andrey Repin wrote:
Yes, I would not expect fast indexed full-text searches across names and content
to ever be a part of the version control system itself. But the functionality
to find filename changes is there - just 'log -v' from the top.
Where you see a reference to full-text search in my quote? I have intentionally
omit that part of your reply.
I think you are asking for a search for the text of a path/filename
across revisions - but maybe that was the way someone else interpreted
the problem. Following an object's path as it may fan out into
different paths/names or be deleted in later revs is a somewhat
different concept and perhaps closer to what you need to convert your
svn log -r 0:head file://${HOME}/trash/repo/f...@3
transparently into
svn log -r 0:4 file://${HOME}/trash/repo/f...@3
But, if you had tagged this version or made similar copies elsewhere or
renamed it, wouldn't you want a forward-following system to track into
the new path(s) as it does going backwards now instead of ending when
one of its names was deleted?
--
Les Mikesell
lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
* Stephen Connolly: Have you considered doing a binary search to find the revision that it was deleted in? svn ls .../t...@2 Exists svn ls .../t...@head No such file in revision 50002 svn ls .../t...@25002 Exists svn ls .../t...@37502 No such file svn ls .../t...@31252 Exists, etc You'll get the revision in at most log2 HEAD iterations If the path has been deleted multiple times, the result won't be stable in the sense that you're guaranteed to get the same answer if further (unrelated) commits are made. This could be quite confusing. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
RE: AW: How to find out the rev number where a file was deleted?
-Original Message- From: Les Mikesell On 11/28/10 12:28 AM, Andrey Repin wrote: 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. From the user's perspective, it's most definitely not the future he's asking Subversion to show, but the past. Thanks for this interesting discussion. I often wondered whether what Andrey is asking was possible and whether there was anything better than my tentative poking at moreless random peg revs in the repo to find the moment a file disappeared, or came into being. Binary search on the 0 to HEAD revision range is a possibility, but it's also a rather wasteful workaround. What's really needed, I think, is an index on the URL maintained by the server that points to the revision ranges where the node existed. That would allow me to do a lookup on any given URL and quickly see whether it has ever existed, and when precisely; or not at all. Due to copying for branches and tags, there will be an explosion of repo URLs. But maybe there is a way to mitigate this. I can see what Andrey is asking for is currently not supported; okay, I'm sure it'll be there in the future. Thanks again for this very good discussion, which clarifies the situation for me. Michael
RE: AW: How to find out the rev number where a file was deleted?
From: Johan Corveleyn 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. A binary search requires that you know at least one rev where the file existed. What if you know (from reading some note) that it did exist, but not when? You can still do a search, but in the worst case you will have to look at every single rev in the repo. Michael
Re: AW: How to find out the rev number where a file was deleted?
On 11/29/2010 4:23 AM, Ludwig, Michael wrote: 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. From the user's perspective, it's most definitely not the future he's asking Subversion to show, but the past. Yes he is, because he is identifying the peg rev but wants the log to give the history of HEAD which is in the future as far as anything that could have been written at the time of that rev, and in fact is a place where the item doesn't exist. Thanks for this interesting discussion. I often wondered whether what Andrey is asking was possible and whether there was anything better than my tentative poking at moreless random peg revs in the repo to find the moment a file disappeared, or came into being. Binary search on the 0 to HEAD revision range is a possibility, but it's also a rather wasteful workaround. Fisheye (a commercial product) does a brute-force extract/index of all the filenames and content in all revs in a repo for quick searches. I'm not sure if there is any equivalent open source program but this is probably the right answer for anyone who needs to do that frequently. If you don't know exactly what you are looking for, you might only remember a piece of content instead of the name. Fisheye can find it either way. What's really needed, I think, is an index on the URL maintained by the server that points to the revision ranges where the node existed. That would allow me to do a lookup on any given URL and quickly see whether it has ever existed, and when precisely; or not at all. There's a big problem here - whether a URL exists or not usually isn't the right answer for things that have been deleted and replaced by something else of the same name. What you usually want is the history of only one of those things - which may track backwards through renames or have been copied from somewhere else. A thing with the same name added later as a replacement may have nothing in common with the item you want. I'm not sure what the right test for this would be other than asking for a log with a rev range and a peg rev to anchor it to one specific version. -- Les Mikesell lesmikes...@gmail.com
RE: AW: How to find out the rev number where a file was deleted?
-Original Message- From: Les Mikesell On 11/29/2010 4:23 AM, Ludwig, Michael wrote: 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. From the user's perspective, it's most definitely not the future he's asking Subversion to show, but the past. Yes he is, because he is identifying the peg rev but wants the log to give the history of HEAD which is in the future as far as anything that could have been written at the time of that rev, and in fact is a place where the item doesn't exist. I can see that from the peg rev point of view, HEAD is the future. But I think we can also agree that from the SVN user's perspective, every single existing rev including HEAD is in the past. What's really needed, I think, is an index on the URL maintained by the server that points to the revision ranges where the node existed. That would allow me to do a lookup on any given URL and quickly see whether it has ever existed, and when precisely; or not at all. There's a big problem here - whether a URL exists or not usually isn't the right answer for things that have been deleted and replaced by something else of the same name. What you usually want is the history of only one of those things - which may track backwards through renames or have been copied from somewhere else. Yes, there could be several items - several revision ranges - in the index, pointing to several unrelated objects. But is it a big problem? In database speak, we'd indeed have a compound key for *uniquely* identifying an object, with the first part of that compound key being the URL, and the second part the revision. But if we don't know the revision, we simply use the URL alone and receive a list of all the items ever to have appeared at that URL. Which ones we're interested in is then a matter of human decision; but gone is the tedium (or wasteful scanning) of establishing the list in the first place. A thing with the same name added later as a replacement may have nothing in common with the item you want. I'm not sure what the right test for this would be other than asking for a log with a rev range and a peg rev to anchor it to one specific version. Give me a listing of the things and either require me to specify which one I want or show them all in full detail, depending on the circumstances. In the special case where there is only one item in the list, no further precision is needed. Best, Michael
Re: AW: How to find out the rev number where a file was deleted?
On 11/29/2010 11:45 AM, Ludwig, Michael wrote: I'd like to be able to see the future too - but unfortunately, neither subversion nor I can do that. From the user's perspective, it's most definitely not the future he's asking Subversion to show, but the past. Yes he is, because he is identifying the peg rev but wants the log to give the history of HEAD which is in the future as far as anything that could have been written at the time of that rev, and in fact is a place where the item doesn't exist. I can see that from the peg rev point of view, HEAD is the future. But I think we can also agree that from the SVN user's perspective, every single existing rev including HEAD is in the past. Yes, but from the perspective of getting history where you can only go backwards, you have to specify the right starting point, and a rev where the thing doesn't exist isn't the right place. Yes, there could be several items - several revision ranges - in the index, pointing to several unrelated objects. But is it a big problem? Yes, if you are in the habit of deleting things and adding them back, then wanting one of the deleted versions. In database speak, we'd indeed have a compound key for *uniquely* identifying an object, with the first part of that compound key being the URL, and the second part the revision. But if we don't know the revision, we simply use the URL alone and receive a list of all the items ever to have appeared at that URL. Which ones we're interested in is then a matter of human decision; but gone is the tedium (or wasteful scanning) of establishing the list in the first place. That's a reasonable thing to want, but perhaps not reasonable for the server to deliver. Would you expect your database to find things for you if you renamed or deleted the table holding them? A thing with the same name added later as a replacement may have nothing in common with the item you want. I'm not sure what the right test for this would be other than asking for a log with a rev range and a peg rev to anchor it to one specific version. Give me a listing of the things and either require me to specify which one I want or show them all in full detail, depending on the circumstances. In the special case where there is only one item in the list, no further precision is needed. It's a big order to make that happen through a client-server connection that has no such existing concept and no server side hints to do it efficiently. Maybe the log facility could have another symbolic token to replace HEAD that would mean you wanted it to find the end-of-the-line for the item if it was deleted. I'd be more inclined to want a separate full-text index and search facility instead of building that into the repository, though. It would be nice if someone could build a free version, perhaps using riaksearch as the underlying tool so the exploded index could be distributed over multiple machines. -- Les Mikesell lesmikes...@gmail.com
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.
Re: AW: How to find out the rev number where a file was deleted?
On 11/27/10 6:42 AM, Paul Maier wrote: Hi Edward, 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. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
On 11/27/10 3:59 PM, Andrey Repin wrote: 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? Because the file doesn't exist in the revision where it was deleted so there's nothing for the log to be about. The change for that rev happened in the directory above. 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. It is not that it isn't tracked. It just isn't tracked where you are looking for it. 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. Subversion tracks things backwards from a starting point that is either something that exists or a peg revision where it did exist. You can find where things were deleted with a 'log -v' of a directory high enough in the repository to contain the change, then use the previous revision as the peg rev for the thing you want to log from there back while it existed. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! 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? Because the file doesn't exist in the revision where it was deleted so there's nothing for the log to be about. That's a flaw, but well, I can live with it as long as there's other ways to get necessary info. The change for that rev happened in the directory above. I'm looking for directory already, as file history would not show me the necessary data. Dunno why... is it hard to track file from PEG revision to first operative revision and print out the logs for every revision, in which that file were changed, and spit the not found in rev X when the file disappear? Why it even think that file could exist in HEAD, when we unambiguously pointed to the specific point in time? 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. It is not that it isn't tracked. It just isn't tracked where you are looking for it. I'm looking for it at revision 2. [C:\]$svn log -v -r 0:HEAD -- http://svn.darkdragon/repos/t...@2 svn: '/repos/!svn/bc/35/test' path not found [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 r1 | anrdaemon | 2009-04-02 17:55:17 +0400 (×ò, 02 àïð 2009) | 2 lines Changed paths: A /test A /test/a Test1 r2 | anrdaemon | 2009-04-02 17:56:13 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: A /test/b test 2 r3 | anrdaemon | 2009-04-02 17:56:48 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: R /test/a Test 3 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. Subversion tracks things backwards from a starting point that is either something that exists or a peg revision where it did exist. I know. Quite. And if you didn't noticed, I specifically specified (LOL) a PEG revision... With exactly that intent - to get around absence of file in HEAD... You can find where things were deleted with a 'log -v' of a directory high enough in the repository to contain the change, then use the previous revision as the peg rev for the thing you want to log from there back while it existed. Project contains 40,000 revisions, about 800 files, like eight branches, that was created/deleted/recreated at some point each, and approximately 25 tags denoting stable builds. Good luck finding directory LOW enough that allow you to find a file without use of a sophisticated log parser, since revision numbers are not connected to changed files in any way suitable for meaningful grep'ing. -- WBR, Andrey Repin (anrdae...@freemail.ru) 28.11.2010, 5:50 Sorry for my terrible english...
Re: AW: How to find out the rev number where a file was deleted?
On 11/27/10 9:06 PM, Andrey Repin wrote: The change for that rev happened in the directory above. I'm looking for directory already, as file history would not show me the necessary data. Dunno why... is it hard to track file from PEG revision to first operative revision and print out the logs for every revision, in which that file were changed, and spit the not found in rev X when the file disappear? It doesn't track the future of a file, it tracks the history. Start with a peg revision of the revision before the delete and the log will track it back through it's entire history. Why it even think that file could exist in HEAD, when we unambiguously pointed to the specific point in time? It won't look towards HEAD unless you request that in the revision range for the log, and then it will be impossible. 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. Actually, while renaming implies deletion, it is not a loss of history. The log of the renamed file will have it, as will the directories containing the changes to the names. It is not that it isn't tracked. It just isn't tracked where you are looking for it. I'm looking for it at revision 2. [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. [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 r1 | anrdaemon | 2009-04-02 17:55:17 +0400 (×ò, 02 àïð 2009) | 2 lines Changed paths: A /test A /test/a Test1 r2 | anrdaemon | 2009-04-02 17:56:13 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: A /test/b test 2 r3 | anrdaemon | 2009-04-02 17:56:48 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: R /test/a Test 3 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. Subversion tracks things backwards from a starting point that is either something that exists or a peg revision where it did exist. I know. Quite. And if you didn't noticed, I specifically specified (LOL) a PEG revision... With exactly that intent - to get around absence of file in HEAD... But you can only expect it to track the history and it appeared that you wanted to track the future to HEAD. I guess it could be more polite about giving you the revisions it can find along with the error. You can find where things were deleted with a 'log -v' of a directory high enough in the repository to contain the change, then use the previous revision as the peg rev for the thing you want to log from there back while it existed. Project contains 40,000 revisions, about 800 files, like eight branches, that was created/deleted/recreated at some point each, and approximately 25 tags denoting stable builds. The tags should be irrelevant since nothing should change there unless you want to use one as source for a copy back to a branch for changes. If you know the file in question existed in a tag, you can track backwards from there though, or copy into a current revision. Good luck finding directory LOW enough that allow you to find a file without use of a sophisticated log parser, since revision numbers are not connected to changed files in any way suitable for meaningful grep'ing. I'd probably feed the output to an editor or 'less', search for the delete of the path than back up to the revision. There are probably fancier things you could do with the xml output. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! The change for that rev happened in the directory above. I'm looking for directory already, as file history would not show me the necessary data. Dunno why... is it hard to track file from PEG revision to first operative revision and print out the logs for every revision, in which that file were changed, and spit the not found in rev X when the file disappear? 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. of the revision before the delete and the log will track it back through it's entire history. Why it even think that file could exist in HEAD, when we unambiguously pointed to the specific point in time? It won't look towards HEAD unless you request that in the revision range for the log, and then it will be impossible. I specified PEG revision. Documentation clearly states that PEG revision has precedence over operative revision in conflicting names resolution, but for absent files (name conflicting with void) it not seems to be the case. 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. Actually, while renaming implies deletion, it is not a loss of history. Yes, but it's still a deletion. The log of the renamed file will have it, as will the directories containing the changes to the names. Unfortunatelly. It only show that file was renamed, but does not show the new name. (Or old name? One of them - see the log below) It is not that it isn't tracked. It just isn't tracked where you are looking for it. I'm looking for it at revision 2. [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. 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) 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. See the order of instructions? Do I need to refer to the svnbook chapter discussing PEG and operative revisions, or you can find it yourself? [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 r1 | anrdaemon | 2009-04-02 17:55:17 +0400 (×ò, 02 àïð 2009) | 2 lines Changed paths: A /test A /test/a Test1 r2 | anrdaemon | 2009-04-02 17:56:13 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: A /test/b test 2 r3 | anrdaemon | 2009-04-02 17:56:48 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: R /test/a Test 3 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. Subversion tracks things backwards from a starting point that is either something that exists or a peg revision where it did exist. I know. Quite. And if you didn't noticed, I specifically specified (LOL) a PEG revision... With exactly that intent - to get around absence of file in HEAD... But you can only expect it to track the history and it appeared that you wanted to track the future to HEAD. I could have pointed to any other of the revisions between @PEG and HEAD, which will net the very same result - unless I guess it right, the process will not start at all. I guess it could be more polite about giving you the revisions it can find along with the error. 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. -- WBR, Andrey Repin (anrdae...@freemail.ru) 28.11.2010, 9:13 Sorry for my terrible english...
Re: AW: How to find out the rev number where a file was deleted?
Have you considered doing a binary search to find the revision that it was deleted in? svn ls .../t...@2 Exists svn ls .../t...@head No such file in revision 50002 svn ls .../t...@25002 Exists svn ls .../t...@37502 No such file svn ls .../t...@31252 Exists, etc You'll get the revision in at most log2 HEAD iterations - Stephen --- Sent from my Android phone, so random spelling mistakes are a direct result of using swype to type on the screen On 28 Nov 2010 06:30, Andrey Repin anrdae...@freemail.ru wrote: Greetings, Les Mikesell! The change for that rev happened in the directory above. I'm looking for directory alread... 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. of the revision before the delete and the log will track it back through it's entire history. ... I specified PEG revision. Documentation clearly states that PEG revision has precedence over operative revision in conflicting names resolution, but for absent files (name conflicting with void) it not seems to be the case. I can understand that it's not easy to track deletes/copies forward, but tracking history... Yes, but it's still a deletion. The log of the renamed file will have it, as will the directories containing the changes to the... Unfortunatelly. It only show that file was renamed, but does not show the new name. (Or old name? One of them - see the log below) It is not that it isn't tracked. It just isn't tracked where you are looking for it. ... 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. 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) 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. See the order of instructions? Do I need to refer to the svnbook chapter discussing PEG and operative revisions, or you can find it yourself? [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 ---... I could have pointed to any other of the revisions between @PEG and HEAD, which will net the very same result - unless I guess it right, the process will not start at all. I guess it could be more polite about giving you the revisions it can find along with the error... 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. -- WBR, Andrey Repin (anrdae...@freemail.ru) 28.11.2010, 9:13 Sorry for my terrible english...
