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 earlie
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
th
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
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 fo
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, w
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
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
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
On Sun, Nov 28, 2010 at 7:28 AM, Andrey Repin wrote:
> 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 revisi
[ 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 t
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 whi
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 as
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 inf
On Sun, Nov 28, 2010 at 6:35 PM, Daniel Shahaf 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 mod
Johan Corveleyn wrote on Sun, Nov 28, 2010 at 21:20:28 +0100:
> On Sun, Nov 28, 2010 at 6:35 PM, Daniel Shahaf
> 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 aspe
On Sun, Nov 28, 2010 at 7:59 AM, 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
* 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
> Ex
> -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 fu
> 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 informati
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
> -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
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 id
> -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
> > t
Greetings, Les Mikesell!
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
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 y
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
> -Original Message-
> From: Les Mikesell
> On 11/30/10 5:21 AM, Ludwig, Michael wrote:
> >
> > 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 1b
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
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 ten
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
> -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
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 h
> 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
33 matches
Mail list logo
