Author: Alan Date: To: tails-ux Subject: Re: [Tails-ux] Ever-growing blueprint/ directory on the website
Hi,
intrigeri <intrigeri@???> wrote: > sajolida wrote (26 Feb 2015 11:44:08 GMT) :
> > But for the Greeter for example, we also used Redmine to store
> > attachments. So we could set an informal rule to push text and XML to
> > Git, and binary images to Redmine. The biggest SVG file called
> > greeter-flow.png probably inlines several PNG files and that's why it
> > got bigger.
> [...] > > We need to be able to insert those binary images into the blueprints.
> > I'm not sure ikiwiki knows how to do that for remote URLs
>
> Apparently not with the img plugin.
> Too bad.
> > but in the worse case we can do that through HTML.
>
> Cool.
>
> So, problem solved apparently. Yay!
> We should then somehow document this.
> Do we need to enforce this server-side, to forbid pushing large files,
> possibly with a per-file-extension limit?
>
> I definitely trust that mistakes will be rare, but one can *not* undo
> such mistakes, as far as the `.git' directory size is concerned, which
> is what I'm interested in right now... and I'd like to avoid having to
> rewrite the Git history again in a few years, sort of. OTOH, I can
> definitely do more interesting things than setting up Git hooks :)
>
> I'll let you judge.
> I think that as blueprints are publicly editable en enforcing
mechanism would be good.
%20:%0A>%20>%20>%20But%20for%20the%20Greeter%20for%20example,%20we%20also%20used%20Redmine%20to%20store%0A>%20>%20>%20attachments.%20So%20we%20could%20set%20an%20informal%20rule%20to%20push%20text%20and%20XML%20to%0A>%20>%20>%20Git,%20and%20binary%20images%20to%20Redmine.%20The%20biggest%20SVG%20file%20called%0A>%20>%20>%20greeter-flow.png%20probably%20inlines%20several%20PNG%20files%20and%20that's%20why%20it%0A>%20>%20>%20got%20bigger.%0A>%20>%20%0A>%20%5B...%5D%0A>%20>%20>%20We%20need%20to%20be%20able%20to%20insert%20those%20binary%20images%20into%20the%20blueprints.%0A>%20>%20>%20I'm%20not%20sure%20ikiwiki%20knows%20how%20to%20do%20that%20for%20remote%20URLs%0A>%20>%20%0A>%20>%20Apparently%20not%20with%20the%20img%20plugin.%0A>%20>%20%0A>%20Too%20bad.%0A>%20%0A>%20>%20>%20but%20in%20the%20worse%20case%20we%20can%20do%20that%20through%20HTML.%0A>%20>%20%0A>%20>%20Cool.%0A>%20>%20%0A>%20>%20So,%20problem%20solved%20apparently.%20Yay!%0A>%20>%20%0A>%20We%20should%20then%20somehow%20document%20this.%0A>%20%0A>%20>%20Do%20we%20need%20to%20enforce%20this%20server-side,%20to%20forbid%20pushing%20large%20files,%0A>%20>%20possibly%20with%20a%20per-file-extension%20limit?%0A>%20>%20%0A>%20>%20I%20definitely%20trust%20that%20mistakes%20will%20be%20rare,%20but%20one%20can%20*not*%20undo%0A>%20>%20such%20mistakes,%20as%20far%20as%20the%20%60.git'%20directory%20size%20is%20concerned,%20which%0A>%20>%20is%20what%20I'm%20interested%20in%20right%20now...%20and%20I'd%20like%20to%20avoid%20having%20to%0A>%20>%20rewrite%20the%20Git%20history%20again%20in%20a%20few%20years,%20sort%20of.%20OTOH,%20I%20can%0A>%20>%20definitely%20do%20more%20interesting%20things%20than%20setting%20up%20Git%20hooks%20:)%0A>%20>%20%0A>%20>%20I'll%20let%20you%20judge.%0A>%20>%20%0A>%20I%20think%20that%20as%20blueprints%20are%20publicly%20editable%20en%20enforcing%0A>%20mechanism%20would%20be%20good.%0A>%20%0A>%20 "Reply to this message")