However Alexandre doesn't like binary files in the CVS
for good reasons
While I can see that to a point, it's not 100% clear to me that storing a .gif (or what have you) in CVS is such a bad idea. I mean, the main advantage of storing stuff as plain text is to be able to look at (and undrestand :)) the diffs. However, that's not the case for images, even when stored in a text format.
CVS can handle binary files no problem. Can someone please refresh my memory on why storing binary _images_ in CVS is such a bad idea?
I think it is because CVS can't store the diffs between binary files. It stores the whole file even if only one byte change. So it takes a lot of space to store the history of the file.
Of course storing space is cheap nowadays...
On Sat, 4 May 2002, Patrik Stridvall wrote: [...]
CVS can handle binary files no problem. Can someone please refresh my memory on why storing binary _images_ in CVS is such a bad idea?
I think it is because CVS can't store the diffs between binary files. It stores the whole file even if only one byte change. So it takes a lot of space to store the history of the file.
Of course storing space is cheap nowadays...
But I believe it makes CVS slower too. Especially if you changed the file or if you 'touched' it by mistake.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
On May 4, 2002 04:22 am, Francois Gouget wrote:
On Sat, 4 May 2002, Patrik Stridvall wrote: [...]
CVS can handle binary files no problem. Can someone please refresh my memory on why storing binary _images_ in CVS is such a bad idea?
I think it is because CVS can't store the diffs between binary files. It stores the whole file even if only one byte change. So it takes a lot of space to store the history of the file.
Of course storing space is cheap nowadays...
But I believe it makes CVS slower too. Especially if you changed the file or if you 'touched' it by mistake.
To reply to both these at the same time: I have worked on projects that had all their .gif files in CVS. Thousands of them. Space and speed were not a problem, despite the large number of users we had, and the antiquated machine (by todays standards) we were running the CVS server on. In wine we have a (maybe) a few tens, or at most a hundred, _small_ images. Storage space and speed is _not_ a problem.
As for the cvs -t argument, ... Oh, come on! :)
I would argue that compatibility with MS' rc is more important...
-- Dimi.
I would argue that compatibility with MS' rc is more important...
I would too.
About the resources, Eric Kohl told me one time the plain txt rc was due to endiness issues on non-x86 platforms. I dont really see how thats a issue if the platform supports GIF/JPEG but I dont understand how alot of things do and dont work.
Steven
__________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
"Dimitrie O. Paun" dimi@bigfoot.com writes:
I would argue that compatibility with MS' rc is more important...
I don't see why this is so important. The resource compiler is included in the tree, and should be pretty trivial to make work on any platform that you want to build Wine on. And if it doesn't work right it needs to be fixed; I don't see why we need to introduce extra complexity to use another compiler.
Besides, if someone really wants to use the MS compiler, it would be pretty trivial to enhance bin2res to generate MS-compatible files from the Wine sources. There's no need to ship binary files for that.
On May 4, 2002 09:39 pm, Alexandre Julliard wrote:
Besides, if someone really wants to use the MS compiler, it would be pretty trivial to enhance bin2res to generate MS-compatible files from the Wine sources. There's no need to ship binary files for that.
OK, I'm convinced :) I fact, I don't care much about MS rc, is just that I don't see having a few small, seldom changing images in the tree being that big of a problem...
-- Dimi.
Besides, if someone really wants to use the MS
compiler, it would be
pretty trivial to enhance bin2res to generate
MS-compatible files from
the Wine sources. There's no need to ship binary
files for that.
OK, I'm convinced :) I fact, I don't care much about MS rc, is just that I don't see having a few small, seldom changing images in the tree being that big of a problem...
I agree but untill it is fixed mingw/MS_VC are SOL. Anyone want to help the MS_VC and Mingw port out by fixing wrc to output compatable rc files? Currently winebuild reads the wrc resources from the spec file which is not going to be used in the mingw/VC++ port. I dont know if MS_VC can link to windress compiled resources but if it can then that would be a good place to look for information on how to fix wrc.
I will start a bug in bugzilla to address this issue.
Thanks Steven
__________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
I will start a bug in bugzilla to address this issue.
(wrc does not generate resources that can be used on Mingw and MS_VC)
http://bugs.winehq.com/show_bug.cgi?id=645
__________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
Steven Edwards steven_ed4153@yahoo.com writes:
I agree but untill it is fixed mingw/MS_VC are SOL. Anyone want to help the MS_VC and Mingw port out by fixing wrc to output compatable rc files? Currently winebuild reads the wrc resources from the spec file which is not going to be used in the mingw/VC++ port.
I'm not sure I understand the problem. wrc generates .res files that should work just fine with MS VC or windres. Why doesn't this work?
I'm not sure I understand the problem. wrc generates .res files that should work just fine with MS VC or windres. Why doesn't this work?
The last time I tried(two months back) it wouldn't work. I will double check tonight and email you a full report of my attempts/problems.
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson
On Sat, May 04, 2002 at 09:57:26AM +0200, Patrik Stridvall wrote:
However Alexandre doesn't like binary files in the CVS
for good reasons
...
CVS can handle binary files no problem. Can someone please refresh my memory on why storing binary _images_ in CVS is such a bad idea?
I think it is because CVS can't store the diffs between binary files. It stores the whole file even if only one byte change. So it takes a lot of space to store the history of the file.
When you change an image, then the file changes completely in many cases anyway, so storing it in binary form just *saves* storage and bandwidth in the normal case. It's just a bit inconvenient for cvs -t fans, but that's all I can come up with right now (and there's a workaround for that).
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
-
Alexandre Julliard -
Dimitrie O. Paun -
Francois Gouget -
Joerg Mayer -
Patrik Stridvall -
Steven Edwards