Show file sizes in "Show Log" window and similar
Ralf Onat
Would it be possible to add another column to the file modification listviews to show the actual size of files?
I have some monolithic binary files where I change data a lot and they constantly grow in size. With this change I would be able to monitor if/where a large change of size occurs and track it down.
I have attached a modified screenshot (red text) showing what I mean.
Thoughts?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627286
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
Andy Levy
> I did a quick search on the mailing lists, the old/new trackers and this forum and was unable to come up with any hits so here goes:
>
> Would it be possible to add another column to the file modification listviews to show the actual size of files?
>
> I have some monolithic binary files where I change data a lot and they constantly grow in size. With this change I would be able to monitor if/where a large change of size occurs and track it down.
>
> I have attached a modified screenshot (red text) showing what I mean.
>
> Thoughts?
Subversion doesn't store the size of each file as metadata, so to do
this one would have to run svn cat against each file's URL for each
revision & count the bytes. To do so would be extremely expensive.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627305
Ralf Onat
> this one would have to run svn cat against each file's URL for each
> revision & count the bytes. To do so would be extremely expensive.
I guess it's unlikely that this change can be pushed into subversion then? What would be your guess?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627321
Andy Levy
>> Subversion doesn't store the size of each file as metadata, so to do
>> this one would have to run svn cat against each file's URL for each
>> revision & count the bytes. To do so would be extremely expensive.
>
> I guess it's unlikely that this change can be pushed into subversion then? What would be your guess?
I would guess that it'd be a very hard argument to win. Such a feature
would hammer disk & network (since you can't stream a diff to the
client, each operation would require the full file) I/O & have the
potential to be very easily abused.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627337
Ralf Onat
> >> this one would have to run svn cat against each file's URL for each
> >> revision & count the bytes. To do so would be extremely expensive.
> >
> > I guess it's unlikely that this change can be pushed into subversion then? What would be your guess?
>
> I would guess that it'd be a very hard argument to win. Such a feature
> would hammer disk & network (since you can't stream a diff to the
> client, each operation would require the full file) I/O & have the
> potential to be very easily abused.
Err. Sorry I was referring to *SUBVERSION* storing the file size within the metadata! So TSVN can just display the size without any additional overhead.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627358
Andy Levy
>> >> Subversion doesn't store the size of each file as metadata, so to do
>> >> this one would have to run svn cat against each file's URL for each
>> >> revision & count the bytes. To do so would be extremely expensive.
>> >
>> > I guess it's unlikely that this change can be pushed into subversion then? What would be your guess?
>>
>> I would guess that it'd be a very hard argument to win. Such a feature
>> would hammer disk & network (since you can't stream a diff to the
>> client, each operation would require the full file) I/O & have the
>> potential to be very easily abused.
>
> Err. Sorry I was referring to *SUBVERSION* storing the file size within the metadata! So TSVN can just display the size without any additional overhead.
Similar answer. When Subversion stores each revision in the
repository, it often will only store the diff. So to record this, it
would have to internally "svn cat" the whole file to get a file size.
On a large commit, this could be very expensive. I'm not sure that the
commit process could handle calculating it on the client end &
transmitting it as part of the commit; there may be some huge holes in
that idea which I can't think of offhand.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627360
Konstantin Kolinko
> On Tue, Jun 29, 2010 at 09:37, Ralf Onat <kongo...@gmx.net> wrote:
>>> >> Subversion doesn't store the size of each file as metadata, so to do
>>> >> this one would have to run svn cat against each file's URL for each
>>> >> revision & count the bytes. To do so would be extremely expensive.
>>> >
>>> > I guess it's unlikely that this change can be pushed into subversion then? What would be your guess?
>>>
>>> I would guess that it'd be a very hard argument to win. Such a feature
>>> would hammer disk & network (since you can't stream a diff to the
>>> client, each operation would require the full file) I/O & have the
>>> potential to be very easily abused.
>>
>> Err. Sorry I was referring to *SUBVERSION* storing the file size within the metadata! So TSVN can just display the size without any additional overhead.
>
> Similar answer. When Subversion stores each revision in the
> repository, it often will only store the diff. So to record this, it
> would have to internally "svn cat" the whole file to get a file size.
> On a large commit, this could be very expensive. I'm not sure that the
> commit process could handle calculating it on the client end &
> transmitting it as part of the commit; there may be some huge holes in
> that idea which I can't think of offhand.
>
Because of svn:eol-style handling the file size will be different on
different platforms. There is also svn:keywords.
And I do not think that the feature asked by the OP will be useful.
Best regards,
Konstantin Kolinko
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627362
Greywolf
of the metadata field will be.
Now you COULD do an approximation as a pre-commit hook by simply doing
effectively a 'ls -l' or equivalent and parsing it out, and then apply that as a
property at checkin time.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627411
Andy Levy
> Showing file sizes somewhere in metadata. The problem is agreeing what the name
> of the metadata field will be.
>
> Now you COULD do an approximation as a pre-commit hook by simply doing
> effectively a 'ls -l' or equivalent and parsing it out, and then apply that as a
> property at checkin time.
As noted by Konstantin, different environments will have different EOL
markers if you set svn:eol-style to native. \r vs. \r\n (vs. other?).
This will result in different sizes reported for the same file with
the same number of characters otherwise. And do you count expanded
keywords or not? If you don't intend to, then ls -l don't provide the
correct answer.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627412
Greywolf
> On Tue, Jun 29, 2010 at 13:18, Greywolf<grey...@starwolf.com> wrote:
>> Showing file sizes somewhere in metadata. The problem is agreeing what the name
>> of the metadata field will be.
>>
>> Now you COULD do an approximation as a pre-commit hook by simply doing
>> effectively a 'ls -l' or equivalent and parsing it out, and then apply that as a
>> property at checkin time.
>
> As noted by Konstantin, different environments will have different EOL
> markers if you set svn:eol-style to native. \r vs. \r\n (vs. other?).
> This will result in different sizes reported for the same file with
> the same number of characters otherwise. And do you count expanded
> keywords or not? If you don't intend to, then ls -l don't provide the
> correct answer.
This depends, of course, on the degree of precision you want.
If you do 'ls -sH' or something, you get the "human readable"
version which, in most cases, is "good enough".
Your point is taken, though -- if "good enough" isn't, then yeah,
there's an issue.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2627425
Ralf Onat
How about a workaround? Is it possible with current tools to semi-automatically get the file sizes of a file for each revision?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2628165
Konstantin Kolinko
> Alright. I guess this won't make it into svn in the next couple years.
>
> How about a workaround? Is it possible with current tools to semi-automatically get the file sizes of a file for each revision?
>
svn list --xml
in svn 1.6 mentions sizes of the files,
and that is the size of pristine file
(.svn/text-base/<filename>.svn-base), i.e. with LF endings (if
svn:eol-style = native) and keywords not expanded.
Best regards,
Konstantin Kolinko
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2628174
Andy Levy
> 2010/7/1 Ralf Onat <kongo...@gmx.net>:
>> Alright. I guess this won't make it into svn in the next couple years.
>>
>> How about a workaround? Is it possible with current tools to semi-automatically get the file sizes of a file for each revision?
>>
>
> svn list --xml
> in svn 1.6 mentions sizes of the files,
> and that is the size of pristine file
> (.svn/text-base/<filename>.svn-base), i.e. with LF endings (if
> svn:eol-style = native) and keywords not expanded.
>
Since that uses .svn, I would assume that's only for the current local
copy - not versions in the past in the repository.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2628176
Andy Levy
> Alright. I guess this won't make it into svn in the next couple years.
>
> How about a workaround? Is it possible with current tools to semi-automatically get the file sizes of a file for each revision?
Going back to my first reply, to do this one would have to run svn cat
against each file's URL for each revision & count the bytes (or
possibly, in light of Konstantin's post, check out or update to every
revision & then check). To do this would be extremely expensive. As a
repository administrator, I would not be happy if someone ran this
against my server.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2628177
Gert Kello
Since that uses .svn, I would assume that's only for the current local
copy - not versions in the past in the repository.
svn --verbose list http://tortoisesvn.googlecode.com/svn/trunk/ -r 19000
Gert
Andy Levy
OK, so now you're talking about running that operation against every
revision & pushing a lot of work on the server just to calculate file
sizes. --verbose seems to at least double the time required to perform
an svn list on a URL with only a half-dozen child elements, all but of
which are directories. On a more heavily-populated directory, the
difference is about 10 seconds (I'm on windows, so I can't use a
simple time-measuring tool like time) with vs. without --verbose.
--verbose also pegs the server CPU for a portion of that time (about
half of it). Both cause a rise in server memory usage too - with
--verbose adding about 10X the memory load on my 1.5.2 server (memory
usage for httpd.exe went up 4MB for svn list, and up 46MB for svn list
--verbose).
Putting my repository/server admin hat back on - please don't do this
repeatedly against my server as is being suggested by the OP.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2628181
Ralf Onat
> against each file's URL for each revision & count the bytes (or
> possibly, in light of Konstantin's post, check out or update to every
> revision & then check). To do this would be extremely expensive. As a
> repository administrator, I would not be happy if someone ran this
> against my server.
No worries, I only want to do this *to my own local repo* once or twice a year to check the development of the file size.
So which approach would be better/faster? the svn cat or the svn list --verbose one?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2628236
Andy Levy
>> Going back to my first reply, to do this one would have to run svn cat
>> against each file's URL for each revision & count the bytes (or
>> possibly, in light of Konstantin's post, check out or update to every
>> revision & then check). To do this would be extremely expensive. As a
>> repository administrator, I would not be happy if someone ran this
>> against my server.
>
> No worries, I only want to do this *to my own local repo* once or twice a year to check the development of the file size.
>
> So which approach would be better/faster? the svn cat or the svn list --verbose one?
I would guess svn list --verbose but there will be variations based on
the type of content you're actually processing. Test with your own
data.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2628289
Ralf Onat
So seems to me like it works nicely and seems already implemented in svn?
So let me ask again: Would it be possible to show this information in TSVN? Maybe (so it doesnt change the current speed for retrieval) even a button "fetch file sizes"?
Thanks in advance.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2628628
Ralf Onat
>
> So seems to me like it works nicely and seems already implemented in svn?
>
> So let me ask again: Would it be possible to show this information in TSVN? Maybe (so it doesnt change the current speed for retrieval) even a button "fetch file sizes"?
>
> Thanks in advance.
*bump*
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2632179
Simon Large
>> OK. I just did a "svn log" to get the rev numbers for a file certain file and then looped a "svn list --verbose -r xxx svn://...." against each revision. Took 1 sec for roughly 1000 revisions to get the history of all file revision sizes.
>>
>> So seems to me like it works nicely and seems already implemented in svn?
>>
>> So let me ask again: Would it be possible to show this information in TSVN? Maybe (so it doesnt change the current speed for retrieval) even a button "fetch file sizes"?
>>
>> Thanks in advance.
>
> *bump*
Let me ask you a question: how many people would this change benefit?
My guess is 1 since no-one has ever asked for such a feature before,
and it would add another button to an already busy user interface.
The repo browser shows file sizes already at whatever revision you are
looking at, which will be enough for most people. Seeing the file size
for every file in every commit is pretty specific to you. Your best
bet is to write a script which calls the svn client and parses the xml
output. Maybe you could then get it to show deltas, which would help
you pick out the revisions where a large change occurred.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2632195
Stefan Wild
> On 12 July 2010 07:44, Ralf Onat<kongo...@gmx.net> wrote:
>>> OK. I just did a "svn log" to get the rev numbers for a file certain file and then looped a "svn list --verbose -r xxx svn://...." against each revision. Took 1 sec for roughly 1000 revisions to get the history of all file revision sizes.
>>>
>>> So seems to me like it works nicely and seems already implemented in svn?
>>>
>>> So let me ask again: Would it be possible to show this information in TSVN? Maybe (so it doesnt change the current speed for retrieval) even a button "fetch file sizes"?
>>>
>>> Thanks in advance.
>> *bump*
> Let me ask you a question: how many people would this change benefit?
> My guess is 1 since no-one has ever asked for such a feature before,
> and it would add another button to an already busy user interface.
>
> The repo browser shows file sizes already at whatever revision you are
> looking at, which will be enough for most people. Seeing the file size
> for every file in every commit is pretty specific to you. Your best
> bet is to write a script which calls the svn client and parses the xml
> output. Maybe you could then get it to show deltas, which would help
> you pick out the revisions where a large change occurred.
>
> Simon
I've followed this discussion for a while and I wonder why it's always the *good* suggestions that are rejected. I think that would be a very useful feature since I missed it in some situations.
--
Mit freundlichen Grüßen
Stefan Wild
autinity systems GmbH
Neefestraße 42
D-09119 Chemnitz
Amtsgericht Chemnitz HRB: 21552
Telefon: +49 (0) 371 918897-50
Fax: +49 (0) 371 918897-49
email: stefa...@autinity.de
web: www.autinity.de
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2632207
Stefan Küng
Useful for what? In what situation would that info had helped you and
in what way?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2632337
Stefan Wild
>> I've followed this discussion for a while and I wonder why it's always the *good* suggestions that are rejected. I think that would be a very useful feature since I missed it in some situations.
> Useful for what? In what situation would that info had helped you and
> in what way?
>
> Stefan
I know that each of you does this voluntary, so it's at last your choice, but if I understood the last answers it would not be very expensive.
--
Mit freundlichen Grüßen
Stefan Wild
autinity systems GmbH
Neefestraße 42
D-09119 Chemnitz
Amtsgericht Chemnitz HRB: 21552
Telefon: +49 (0) 371 918897-50
Fax: +49 (0) 371 918897-49
email: stefa...@autinity.de
web: www.autinity.de
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2632597
Felix Saphir
> Am 12.07.2010 14:18, schrieb Stefan Küng:
>>> I've followed this discussion for a while and I wonder why it's
>>> always the *good* suggestions that are rejected. I think that
>>> would be a very useful feature since I missed it in some
>>> situations.
>> Useful for what? In what situation would that info had helped you
>> and in what way?
>>
> differs between revisions. So you can easily find out if it's a big
> or small change without having to use the diff tool. Unfortunately,
> some of my coworkers did *not* use the svn comment feature, so it's
> impossible to find out information that way. Besides, you can't even
> use the diff tool for binary data, which was the main reason for Ralf
> to submit this request.
>
Sorry, but I still don't understand how this information could be
useful. What exactly do you gain from knowing that the difference is
12.34 kB big? Why should your coworkers put that information in a comment?
Felix
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2632696
Stefan Wild
> Stefan Wild schrieb:
>> Am 12.07.2010 14:18, schrieb Stefan Küng:
>>>> I've followed this discussion for a while and I wonder why it's
>>>> always the *good* suggestions that are rejected. I think that
>>>> would be a very useful feature since I missed it in some
>>>> situations.
>>> Useful for what? In what situation would that info had helped you
>>> and in what way?
>> As Ralf said, it's sometimes useful to know if and how much size
>> differs between revisions. So you can easily find out if it's a big
>> or small change without having to use the diff tool. Unfortunately,
>> some of my coworkers did *not* use the svn comment feature, so it's
>> impossible to find out information that way. Besides, you can't even
>> use the diff tool for binary data, which was the main reason for Ralf
>> to submit this request.
> Sorry, but I still don't understand how this information could be
> useful. What exactly do you gain from knowing that the difference is
> 12.34 kB big? Why should your coworkers put that information in a comment?
>
> Felix
if every commit was made with a detailed and easy-to-understand comment, you would know exactly what was changed in every revision. But because rather to find such, you could either search through every diff to find out if this was just a fixed line ending or a great change - or you could look at the sizes.
I think that's as important to know as the timestamp of the file.
--
Mit freundlichen Grüßen
Stefan Wild
autinity systems GmbH
Neefestraße 42
D-09119 Chemnitz
Amtsgericht Chemnitz HRB: 21552
Telefon: +49 (0) 371 918897-50
Fax: +49 (0) 371 918897-49
email: stefa...@autinity.de
web: www.autinity.de
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2632715
Felix Saphir
> Am 13.07.2010 13:23, schrieb Felix Saphir:
>> Stefan Wild schrieb:
>>
>>> differs between revisions. So you can easily find out if it's a
>>> big or small change without having to use the diff tool.
>>> Unfortunately, some of my coworkers did *not* use the svn comment
>>> feature, so it's impossible to find out information that way.
>>> Besides, you can't even use the diff tool for binary data, which
>>> was the main reason for Ralf to submit this request.
>>
>> Sorry, but I still don't understand how this information could be
>> useful. What exactly do you gain from knowing that the difference
>> is 12.34 kB big? Why should your coworkers put that information in
>> a comment?
>
> easy-to-understand comment, you would know exactly what was changed
> in every revision. But because rather to find such, you could either
> search through every diff to find out if this was just a fixed line
> ending or a great change - or you could look at the sizes. I think
> that's as important to know as the timestamp of the file.
So you want to "know exactly what was changed" from the size of the
diff? I don't think that's what you meant to say. Wouldn't it be better
to "educate" your coworkers to write better commit messages?
Felix
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2632725
Konstantin Kolinko
> Unfortunately, some of my coworkers did *not* use the svn comment feature,
Note, that you can force them to write log messages. Either by setting
tsvn:logminsize property on the root folder of your project [1] if all
of them are using TortoiseSVN, or with a server-side hook if a general
solution is needed.
Best regards,
Konstantin Kolinko
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2632900
Stefan Wild
You surely know how software engineers are... @Konstantin: you can also write "too much" or "something" as a comment if you are forced to.
After all, me and surely some others would benefit from this feature, and it seems that adding this feature would cost less time than to discuss if it's really necassary and why and for whom.
Again, it's at last your choice.
--
Mit freundlichen Grüßen
Stefan Wild
autinity systems GmbH
Neefestraße 42
D-09119 Chemnitz
Amtsgericht Chemnitz HRB: 21552
Telefon: +49 (0) 371 918897-50
Fax: +49 (0) 371 918897-49
email:stefa...@autinity.de
web:www.autinity.de
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633083
Stefan Küng
> that wasn't really what I meant to say. But as some of you probably
> know, the size is an important attribute for a file - such as time
> and file name. You surely know how software engineers are...
> @Konstantin: you can also write "too much" or "something" as a
> comment if you are forced to.
>
> After all, me and surely some others would benefit from this feature,
> and it seems that adding this feature would cost less time than to
If you think you can implement it that fast, why don't you give it a try
and send us the patch?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633182
Bjørnar Skinnes
Consider using the bugtrac:xxx properties as explained in the tsvn help
file to couple the commit to the bug tracking system by ids. This will
give you an extra box in the commit ui to input that id.
For the the discussion: even though it might be easy to implement, it is
not a good feature to have tsvn show *a lot* of file sizes, in that I
mean that you would get too much information, that would waste my time
when my brain needs to ignore that unuseful info.
Ohh, a big change is not neccesarily an important change.
Bjørnar
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633366
Ralf Onat
I had hoped that some other people had worked with non-tiny files with (T)SVN before and noticed the same "problem" (not knowing the file sizes / development of file sizes over the course of commits).
It's one of those features where if you don't work with larger files you will never come to think about needing that information.
Anyways. I have followed this discussion for quite some time now and for me it's the time to either:
a) write a small script that does what I want and take it with me everywhere I need it.
b) a dev decides it's a nice feature to have after all and is willing to implement this in the future so all TSVN users can benefit instantly.
Again, thanks for the interesting discussion so far!
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633391
Felix Saphir
> Hmm, this really seems like a black/white topic. Looking at the
> replies I would have to assume that most of you would have the
> "size"-column in windows explorer hidden since that information is
> "useless". I think that it is a very crucial information. I do
> understand that the file size for text files (code, etc) is
> negligible in most cases, but as I initially wrote I am working with
> rather large monolithic files that I need version-controlled.
> (CorelDRAW, Access-MDBs, etc)
>
> I had hoped that some other people had worked with non-tiny files
> with (T)SVN before and noticed the same "problem" (not knowing the
> file sizes / development of file sizes over the course of commits).
>
> It's one of those features where if you don't work with larger files
> you will never come to think about needing that information.
Let me ask you the same question as Stefan Wild: What information
exactly do you gain from knowing the size of the change? *That* is IMHO
the problem here: The usefullness has only been stated but not supported
by a concrete example.
If you can give an example, you might convince more people than by just
stating the usefullness.
Felix
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633400
Ralf Onat
> stating the usefullness.
>
> Felix
Alright. It's pretty simple really. I update my working copy and notice that a file suddenly is 30MB instead of the "usual" 10MB. (This happens sometimes for .MDB files for various reasons).
Then I do a show log and see that 10 commits have happened since my last update. OK so here's the use-case: which of these commits changed the file size so drastically?
PS: of course there are also other reasons why files change in size and you would like to know why/where.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633461
Felix Saphir
>> If you can give an example, you might convince more people than by
>> just stating the usefullness.
>
> notice that a file suddenly is 30MB instead of the "usual" 10MB.
> (This happens sometimes for .MDB files for various reasons).
>
> Then I do a show log and see that 10 commits have happened since my
> last update. OK so here's the use-case: which of these commits
> changed the file size so drastically?
>
> PS: of course there are also other reasons why files change in size
> and you would like to know why/where.
Thanks so far, but that was the obvious part.
You didn't quote the original question: You now know the file size
changed dramatically by 20MB in revision r1234. What do you do with that
information? Would you revert the change? Probably not, because it's
there for a reason. Hopefully someone put that reason in the commit
message and now you can read it.
But what's the use of it? You could read that message without knowing
the filesize.
Please don't get me wrong. What I'd really like to know is, if this
would be a helpful infomration for me as well. I'm also dealing with
binary files in some of my repositories, but never felt the need to know
the change in filesize.
Felix
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633465
Robin Guest
> If you can give an example, you might convince more people than by justAlright. It's pretty simple really. I update my working copy and notice that a file suddenly is 30MB instead of the "usual" 10MB. (This happens sometimes for .MDB files for various reasons).
> stating the usefullness.
>
> Felix
Then I do a show log and see that 10 commits have happened since my last update. OK so here's the use-case: which of these commits changed the file size so drastically?
PS: of course there are also other reasons why files change in size and you would like to know why/where.
Bjørnar Skinnes
You could say, run something like http://mdbdiff.sourceforge.net/ for
diffing the 2 databases. And you can actually create a .js or .vbs
script like the other diff that is included in tsvn for doc, xls, etc.
Alternatively found a post that might be useful:
http://bytes.com/topic/access/answers/692229-diff-msaccess#post2752791
Bjørnar
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633545
Ralf Onat
> diffing the 2 databases. And you can actually create a .js or .vbs
> script like the other diff that is included in tsvn for doc, xls, etc.
>
> Alternatively found a post that might be useful:
> http://bytes.com/topic/access/answers/692229-diff-msaccess#post2752791
>
> Bjørnar
Erm, diffing isn't the topic here. I have a perfectly working diff-tool for mdb integrated in TSVN.
> Thanks so far, but that was the obvious part.
> You didn't quote the original question: You now know the file size
> changed dramatically by 20MB in revision r1234. What do you do with that
> information? Would you revert the change? Probably not, because it's
> there for a reason. Hopefully someone put that reason in the commit
> message and now you can read it.
> But what's the use of it? You could read that message without knowing
> the filesize.
> Please don't get me wrong. What I'd really like to know is, if this
> would be a helpful infomration for me as well. I'm also dealing with
> binary files in some of my repositories, but never felt the need to know
> the change in filesize.
> Felix
It really depends. Depending on who did the change I would like to speak to this person telling him that he potentially did something wrong so he will not do it a second time in the future. Other uses would indeed be reverting the changes from that revision. (very tedious task, running diffs against the "good" commits that followed to just revert the changes from this particular revision).
> You're still just stating *that* it helps you, not *why*. How does knowing
> which revision made 30MB's worth of changes help you? How do you act, based
> on that information?
> colonel32
Yea, basically same response as above. Just wanted to add that there is probably more information in (T)SVN that you don't always need. (Do you need the checkin time of each commit? Is it always relevant?).
Anyways. I do agree this is not something you would need everyday, but since I have found myself in a number of situations over the course of years where I had really appreciated being able to retrieve the info via a simple click/view.
Anyways, I am fine with the solution of a scripted task where I supply repo url and it gives me what I want. It's really just a matter of convenience and in the dev's hands.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633550
Stefan Wild
> It really depends. Depending on who did the change I would like to speak to this person telling him that he potentially did something wrong so he will not do it a second time in the future. Other uses would indeed be reverting the changes from that revision. (very tedious task, running diffs against the "good" commits that followed to just revert the changes from this particular revision).
e.g.
another example: a .jar file is about twice the size (or even much larger) than before - so I can easily see that the developer probably packed too much files into the .jar, e.g. source codes or .bak files in addition
--
Mit freundlichen Grüßen
Stefan Wild
autinity systems GmbH
Neefestraße 42
D-09119 Chemnitz
Amtsgericht Chemnitz HRB: 21552
Telefon: +49 (0) 371 918897-50
Fax: +49 (0) 371 918897-49
email: stefa...@autinity.de
web: www.autinity.de
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633947
Andy Levy
> Am 15.07.2010 15:18, schrieb Ralf Onat:
>> It really depends. Depending on who did the change I would like to speak to this person telling him that he potentially did something wrong so he will not do it a second time in the future. Other uses would indeed be reverting the changes from that revision. (very tedious task, running diffs against the "good" commits that followed to just revert the changes from this particular revision).
>
> e.g.
>
> another example: a .jar file is about twice the size (or even much larger) than before - so I can easily see that the developer probably packed too much files into the .jar, e.g. source codes or .bak files in addition
>
Why is a developer doing this manually in the first place? That should
be part of the build script.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2633993
Stefan Wild
some people do such things. they're called developers.
you can also misconfigure the build script.
just do it or do it not, this discussion doesn't help anyone
--
Mit freundlichen Grüßen
Stefan Wild
autinity systems GmbH
Neefestraße 42
D-09119 Chemnitz
Amtsgericht Chemnitz HRB: 21552
Telefon: +49 (0) 371 918897-50
Fax: +49 (0) 371 918897-49
email: stefa...@autinity.de
web: www.autinity.de
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2634028
Stefan Fuhrmann
I agree with the OP that the size of a change is valuable information.
But because a file size change tells very little about how much of the
content actually changed, I reformulated the feature request:
Please understand that this might not be part of 1.7 and if it is,
it may be relatively slow to run.
-- Stefan^2.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2634620