| 1 |
On Thu, Feb 13, 2014 at 10:30 AM, Kent Fredric <kentfredric@×××××.com> wrote: |
| 2 |
> |
| 3 |
> On 14 February 2014 04:28, Anthony G. Basile <blueness@g.o> wrote: |
| 4 |
>> |
| 5 |
>> 2) You want your vcs to show the diff in that file and you can make sense |
| 6 |
>> of that diff. |
| 7 |
> |
| 8 |
> |
| 9 |
> Though how many of them are "well formatted" SVGs, and how many of them are |
| 10 |
> single-line SVG files without whitespace, such as linefeeds and appropriate |
| 11 |
> indentation? |
| 12 |
> |
| 13 |
> Because diffs are usually not very useful if lots of changes occur on a |
| 14 |
> single line. |
| 15 |
|
| 16 |
If these were really hand-maintained SVG files I could see how it |
| 17 |
might fit into an scm model. However, these are text files in the |
| 18 |
same sense that an assembly language listing generated from a C++ file |
| 19 |
would be. Sure, you could manipulate it by hand, but the reality is |
| 20 |
that upstream is going to change 47 lines in the source and you're |
| 21 |
going to upgrade your gcc and as a result 90% of the 3M line listing |
| 22 |
will change on a small upgrade. Likewise, when upsteam changes their |
| 23 |
desktop icon it isn't going to result in a 3-line change to the SVG |
| 24 |
file. |
| 25 |
|
| 26 |
I guess the question though is whether they cause harm. If the files |
| 27 |
are small and don't cause issues with the scm they're stored in, then |
| 28 |
I don't really see the issue with storing them. It doesn't really |
| 29 |
matter if they're SVG files or uuencoded whatever (though if our tree |
| 30 |
is GPL we need to make source available for anything that has it - |
| 31 |
probably not an issue for SVG unless it is derived from some kind of |
| 32 |
composite). |
| 33 |
|
| 34 |
Rich |
Archives