[Bf-committers] Generating icons overwriting files in SVN.

Sergey Sharybin sergey.vfx at gmail.com
Mon Aug 26 14:12:23 CEST 2013


Let's just punish those folks who updates svg but not re-generate png.
Issue solved! :)


On Mon, Aug 26, 2013 at 6:06 PM, Bastien Montagne <montagne29 at wanadoo.fr>wrote:

> Hi folks,
>
> I made that change because I found out prvicons.png was no more in sync
> with its svg "master" since a long time. I obviously agree that these
> "false" changes to png are not nice (I did not expected them, thought
> svn would stick to binary comparison to detect changes in binary files
> :/ ). Additionally, it’s a bit a pita when sharing patches that add an
> icon, reviewer also has to update png from svg...
>
> I’ll revert (or rather, comment) that change for now, but imho we really
> need to find some way to avoid that kind of disparity, human are far too
> much unreliable when it comes to such tasks!
>
> I like Sergey's solution (rasterize svg in Blender), but this is quite a
> big project I fear. :/
>
> On 26/08/2013 12:35, Sergey Sharybin wrote:
> > Hi,
> >
> > Don't think generating PNG if Inkscape found and using PNG from SVN
> > otherwise will work. We would still need to keep PNG up-to-date in svn,
> so
> > everyone is guaranteed to have up-to-date icons.
> >
> > Making inkscape/imagemagick a dependency is not  a good thing to do as
> well
> > -- blender compilation is already really complicated. So i would rather
> > avoid this.
> >
> > So from suggested alternatives i would prefer reverting that part of
> > changes which generates PNG out of SVG at buildtime. We don't change
> icons
> > so much often anyway.
> >
> > As a long-term solution, think it's better to make SVG a native format
> for
> > icons. Meaning, blender will rasterize SVG itself. Would make any icons
> > size look just as crisp as it could be :)
> >
> >
> > On Mon, Aug 26, 2013 at 4:09 PM, Campbell Barton<ideasman42 at gmail.com
> >wrote:
> >
> >> Recently Bastian committed changes so changes to the SVG icons
> >> automatically generates new PNG's.
> >>
> >> In general this is nice functionality to have, but it has some problems.
> >>
> >> The updated file thats generated overwrites the PNG in svn,
> >> with changes to file modifiy times (moving files or dirs about),
> >> its possible the PNG will get regenerated by building, even if the SVG
> >> wasnt modified.
> >>
> >> So before committing you have to revert the change if it wasnt
> intentional,
> >> then manually touch the PNG so CMake isn't going to try generate the
> >> image again.
> >>
> >>
> >> Normally I check files before committing but sometimes I just commit
> >> if I know I only edited a few files.
> >> but generating overwriting files in svn means you can't be sure other
> >> files aren't chagned too.
> >>
> >>
> >>
> >> Suggest 2 options...
> >>
> >> 1) Store _all_ generated files out of source,
> >>    (this was the case already before icon changes)
> >> Note: since we currently don't have inkscape as a build dependency we
> >> cant remove the PNG's from SVN,
> >>    but we could generate the file to the external dir, if inkscape
> >> isn't found, just copy it from the one in svn.
> >>    This way we get the benefit of icon generation without accidentally
> >> overwriting icons in svn.
> >>
> >> 2) revert icon generation as part of the build process for now.
> >>
> >> A third option could be to remove PNG's from SVN and make
> >> inkscape/imagemagick a build dependency,
> >> but think this makes building more trouble and dont really think its
> >> such a good thing to do.
> >>
> >>
> >> --
> >> - Campbell
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin


More information about the Bf-committers mailing list