Re: [fossil-users] Ignoring files/directories in automated zip files?

[Warren Young]

On Sep 19, 2017, at 9:32 PM, Richard Hipp  wrote:
> 
>  /first-10-checkins  /timeline?n=10=1970-01-01

You could also use this for Tickets reports:

  /bugs   /rptview?rn=3
  /wishlist   /rptview?rn=2

Those being the report IDs of my Feature_Requests and Bugs reports.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ignoring files/directories in automated zip files?

[Florian Balmer]

> To set-up aliases, visit the Setup/URL_Aliases page.

Thanks, that's a very handy feature!

Would you consider enabling "rewriting" of the default webpage URLs,
i.e. by searching the alias list prior to the dispatch table? This
could be controlled by a global setting (potential subtle user trap),
or on a per-alias basis with a special syntax like !ALIAS or ALIAS!
(in analogy to X! to drop CGI variables), but probably only for exact
matches to avoid redirection loops.

This would be useful for example to set default query parameters for
the /timeline webpage without modifications to the skin:

!/timeline → /timeline?y=all=50

or:

/timeline! → /timeline?y=all=50

Original suggestion:

https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg25757.html

--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ignoring files/directories in automated zip files?

[Richard Hipp]

On 9/19/17, Andy Goth  wrote:

> Maybe instead consider URL rewriting so the administrator defines custom
> pages (URIs) which are handled by redirecting to the standard pages.

I have prototyped this idea on trunk.

To set-up aliases, visit the Setup/URL_Aliases page.  For example, if
you create this alias:

  /first-10-checkins  /timeline?n=10=1970-01-01

Then a visit to https://www.fossil-scm.org/fossil/first-10-checkins
will show a timeline of the first 10 check-ins for the project.  (This
alias is currently set up on the server as an example, so that you can
try it.

I need to add documentation.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ignoring files/directories in automated zip files?

[Andy Goth]

On 9/19/2017 5:57 PM, Richard Hipp wrote:
> If having a default ex= value really is needed, perhaps it could be
> provided using alternative URLs - perhaps /abridgedtarball and
> /abridgedzip instead of /tarball and /zip.  Or maybe some other prefix
> that is more succinct than "abridged".  Maybe /exporttarball and
> /exportzip?

Maybe instead consider URL rewriting so the administrator defines custom
pages (URIs) which are handled by redirecting to the standard pages.
This general facility might be more useful than adding special cases to
zip/tar.gz generation.  Apache already provides this feature, so if
Fossil is the CGI backend for part of your Apache site, then you have
everything you need.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ignoring files/directories in automated zip files?

[Richard Hipp]

On 9/19/17, Andy Goth  wrote:
> On 9/19/2017 4:22 PM, BohwaZ wrote:
>> The only way to avoid that is having Composer use your dist zip and have
>> that zip file only contain what should be required.
>
> Put the ex= query parameters directly in the download links on your web
> pages.  When the user clicks Download, the zip or tar.gz file will
> contain the appropriate subset of files.
>
>> In Fossil anyone could just create a make recipe to generate a proper
>> ZIP file and sync it in the unversioned files instead.
>
> Also good.

These are both excellent choices.

Suppose we did as the OP requests and provided a new setting that
specifies the default value for --exclude or ex=.  That would not be
hard to implement.  But it seems like it could lead to a subtle trap
for unwary users.  If one developer turns on the default ex= setting
and another developer is unaware of that and goes to get a tarball,
the second developer might not realize the some files had been
intentionally excluded and spend a lot of time trying to track down
the "bug" in Fossil.

Yes, Git provides a way to have a default ex= value.  But then again,
Git is notorious for leaving subtle traps for tripping up unwary
users.  Fossil is not sinless in that regard, either, but we would at
least like to be less tricky than Git, no?

If having a default ex= value really is needed, perhaps it could be
provided using alternative URLs - perhaps /abridgedtarball and
/abridgedzip instead of /tarball and /zip.  Or maybe some other prefix
that is more succinct than "abridged".  Maybe /exporttarball and
/exportzip?
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ignoring files/directories in automated zip files?

[BohwaZ]

Le 20/09/2017 10:04, Warren Young a écrit :

On Sep 19, 2017, at 3:22 PM, BohwaZ  wrote:


But I'm not sure if I want to implement that in Fossil just because 
another unrelated piece of software makes bad decisions…


I think you have *two* uses of zip/tarball here, not one: Fossil’s
built-in mechanism for providing checkouts to people who can’t/won’t
install Fossil, and your release distribution mechanism.

If you want Fossil to be your HTTP file server for the latter case,
use its unversioned files feature from within your “make dist”
implementation.  The Fossil project works this way: the Downloads page
contents on fossil-scm.org are not dynamically built, they’re static
unversioned files.

In Fossil anyone could just create a make recipe to generate a proper 
ZIP file and sync it in the unversioned files instead.


That’s the province of your build system.  Fossil is not a release
engineering tool.  Fossil’s job stops when you tag the release.
Everything after that belongs to someone else, like Automake.

Fossil may then re-enter the picture with “fossil uv”, but that’s a
separate matter.


Yes I completely agree with you, this seems to be the right way of doing 
things, it just requires more work on my side to adapt to Composer ;)

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ignoring files/directories in automated zip files?

[Andy Goth]

On 9/19/2017 4:22 PM, BohwaZ wrote:
> The only way to avoid that is having Composer use your dist zip and have
> that zip file only contain what should be required.

Put the ex= query parameters directly in the download links on your web
pages.  When the user clicks Download, the zip or tar.gz file will
contain the appropriate subset of files.

> In Fossil anyone could just create a make recipe to generate a proper
> ZIP file and sync it in the unversioned files instead.

Also good.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ignoring files/directories in automated zip files?

[Warren Young]

On Sep 19, 2017, at 3:22 PM, BohwaZ  wrote:
> 
> But I'm not sure if I want to implement that in Fossil just because another 
> unrelated piece of software makes bad decisions…

I think you have *two* uses of zip/tarball here, not one: Fossil’s built-in 
mechanism for providing checkouts to people who can’t/won’t install Fossil, and 
your release distribution mechanism.

If you want Fossil to be your HTTP file server for the latter case, use its 
unversioned files feature from within your “make dist” implementation.  The 
Fossil project works this way: the Downloads page contents on fossil-scm.org 
are not dynamically built, they’re static unversioned files.

> In Fossil anyone could just create a make recipe to generate a proper ZIP 
> file and sync it in the unversioned files instead.

That’s the province of your build system.  Fossil is not a release engineering 
tool.  Fossil’s job stops when you tag the release.  Everything after that 
belongs to someone else, like Automake.

Fossil may then re-enter the picture with “fossil uv”, but that’s a separate 
matter.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ignoring files/directories in automated zip files?

[BohwaZ]

On Sep 18, 2017, at 6:49 PM, BohwaZ  wrote:


I'm looking at ignoring some files when an archive (zip/tarball) is 
created by Fossil.


What’s a good example where you’d want to do that?


In PHP package manager, composer (equivalent to gem in Ruby), the 
complete package repository is cloned and included in the project.


This means that a bunch of tests, docs etc. will be included in every 
project. This is bad as you have to download and store useless files, 
plus this means that security wise you might end up with unsafe code 
that can be run by the webserver. Not good.


The only way to avoid that is having Composer use your dist zip and have 
that zip file only contain what should be required.


Though I think this is a problem of Composer, but its authors are 
against letting the package author decide which directories/files should 
be ignored: https://github.com/composer/composer/issues/1750


So I was wondering if Fossil could do the same as Git to go around that 
Composer shortcoming, as that would have made my life much simpler.


But I'm not sure if I want to implement that in Fossil just because 
another unrelated piece of software makes bad decisions…


In Fossil anyone could just create a make recipe to generate a proper 
ZIP file and sync it in the unversioned files instead.


I might end up just setting up my own Composer repository that would 
serve pre-packaged ZIP files eventually, seems more like a proper 
solution.


Thanks for your help.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ignoring files/directories in automated zip files?

[Warren Young]

On Sep 18, 2017, at 6:49 PM, BohwaZ  wrote:
> 
> I'm looking at ignoring some files when an archive (zip/tarball) is created 
> by Fossil.

What’s a good example where you’d want to do that?

If anything, I find Fossil zip/tarball to produce *less* than I want in a 
release tarball, lacking things like the configure script created from 
configure.ac in Autotools projects, for example.

> Is there a way to do the same thing in Fossil?

Not that I’m aware, though I assume extending the existing *-ignore mechanism 
would be straightforward to one with the itch.

(That’s you, just in case that wasn’t clear. :) )

> If not, would that be considered as a feature for Fossil?

Yes, you should consider writing this feature for Fossil. ;)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users