Re: [fossil-users] [minor] src/style.c:427 → "%
Sorry if I was confusing... You'd only have one body tag, but the class
might change while the page is loaded... and it might be initialized to
something.
You might have CSS like:
-
div.first, div.second, div.third {display: none}
body.start div.first,
body.next div.second,
body.last div.third {display: block}
--
Then a body like:
And some Javascript that did: document.body.className="next";
Note that https://developer.mozilla.org/en-US/docs/Web/HTML/Element/body
points out that you can only have one body in a valid HTML page.
../Dave
On 3 July 2018 at 11:50, Warren Young wrote:
> On Jul 2, 2018, at 9:38 PM, David Mason wrote:
> >
> > It's pretty common to put classes on tags, to use CSS to
> conditionally choose different renderings by simply changing the class of
> the body tag.
>
> I think you’d have to write TH1 code to get Fossil to serve more than one
> tag on a given repository.
>
> That then makes me wonder if that would be another way to trick Fossil
> into serving a second tag. Consider this pseudocode:
>
>
>return [concat ""]
>
>
> I say “pseudocode” because it’s probably horrid Tcl style, if it compiles
> at all. I speak only pidgin Tcl these days.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
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] branch assistance needed
On 7/3/18, Dewey Hylton wrote: > Essentially what I did was to commit a change to a new branch, forget I was > in that branch and committed another unrelated change which should have > gone back to trunk but went into the branch. I made that same mistake myself, recently. See https://www.sqlite.org/src/timeline?c=64df1189 Perhaps the best way to fix this is to cherry-pick the fix into trunk. > then attempted to change > that latest commit by adding a 'trunk' tag and cancelling the new branch > tag. I'm pretty sure that was wrong, but I'm unsure now where to go with > this. I've tried a few other things to no avail, but now even after > executing 'fossil update trunk' the 'fossil branch' command shows I'm still > in the new branch. > > So I have two problems to solve: > 1) how do I properly move commits between branches (and to trunk, in my > case)? Cherry pick. > 2) how do I unfudge my current condition and get back to trunk? > There is a way to undo your fudge. But, since this comes up so rarely, there is not a convenient interface. That is something I suppose I need to work on. -- 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] branch assistance needed
On Jul 3, 2018, at 3:09 PM, Dewey Hylton wrote: > > Essentially what I did was to commit a change to a new branch, forget I was > in that branch and committed another unrelated change which should have gone > back to trunk but went into the branch. That’s no big problem so far. I’ve done it myself, probably more than once. The right way to fix it at this point would be to cherrypick the changes that should have been on trunk from the branch onto trunk: $ fossil up trunk $ fossil merge --cherrypick abcd1234 …etc $ [test] $ fossil ci $ fossil up my-new-branch At that point, what you have is effectively as if you’d done this instead: $ fossil up trunk $ [hack, hack] $ fossil ci $ fossil up my-new-branch $ fossil merge trunk So, it’s an easy cleanup. > I then attempted to change that latest commit by adding a 'trunk' tag and > cancelling the new branch tag. Ow! > I'm pretty sure that was wrong, but I'm unsure now where to go with this. Cleanup is similar to the above, it just creates an uglier timeline: $ fossil up trunk $ fossil merge --integrate my-new-branch $ [test] $ fossil ci $ fossil merge --backout abcd1234 # ID of first checkin on my-new-branch $ [test] $ fossil ci $ fossil merge --cherrypick abcd1234 $ fossil ci my-new-branch You might have to give a checkin ID in the first command instead of a branch name if it isn’t putting you in the timeline where you think you ought to be. Fossil might even complain about having two “trunk” branch tips with this command; if so, the solution is the same. It’s okay to give the same branch name in the last command as you used originally because Fossil just uses branch names as auto-propagating labels. Checkin IDs and their relationships are what matters to Fossil, not branch names. Still, you might prefer to give it a different name to avoid causing yourself confusion, even though Fossil isn’t confused at all. ___ 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] branch assistance needed
1) See the `--cherrypick` switch to `fossil merge`. 2) a. undo the tags you've fiddled with, so that branch=trunk is original trunk and side-branch is branch=side-branch. b. fossil checkout trunk c. fossil merge --cherrypick d. (optional) move the erroneous commit (I'm assuming the last commit on `side-branch`) to branch `mistake` and set to hidden Best, Eduard On 07/03/2018 05:09 PM, Dewey Hylton wrote: I've used fossil for years now with lots of commits to trunk and very few very simple branches which tend to get merged right into trunk after only a few commits. I have managed to get myself in a confusing place with one of my projects. Essentially what I did was to commit a change to a new branch, forget I was in that branch and committed another unrelated change which should have gone back to trunk but went into the branch. I then attempted to change that latest commit by adding a 'trunk' tag and cancelling the new branch tag. I'm pretty sure that was wrong, but I'm unsure now where to go with this. I've tried a few other things to no avail, but now even after executing 'fossil update trunk' the 'fossil branch' command shows I'm still in the new branch. So I have two problems to solve: 1) how do I properly move commits between branches (and to trunk, in my case)? 2) how do I unfudge my current condition and get back to trunk? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] branch assistance needed
On Tue, Jul 3, 2018 at 2:09 PM Dewey Hylton wrote: > I've used fossil for years now with lots of commits to trunk and very few > very simple branches which tend to get merged right into trunk after only a > few commits. I have managed to get myself in a confusing place with one of > my projects. > > Essentially what I did was to commit a change to a new branch, forget I > was in that branch and committed another unrelated change which should have > gone back to trunk but went into the branch. I then attempted to change > that latest commit by adding a 'trunk' tag and cancelling the new branch > tag. I'm pretty sure that was wrong, but I'm unsure now where to go with > this. I've tried a few other things to no avail, but now even after > executing 'fossil update trunk' the 'fossil branch' command shows I'm still > in the new branch. > > So I have two problems to solve: > 1) how do I properly move commits between branches (and to trunk, in my > case)? > 2) how do I unfudge my current condition and get back to trunk? > This would be a candidate for “pop latest commit (to stash??)” functionality if the (apparently fiddly) touched pieces could all be identified. -bch > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] branch assistance needed
I've used fossil for years now with lots of commits to trunk and very few very simple branches which tend to get merged right into trunk after only a few commits. I have managed to get myself in a confusing place with one of my projects. Essentially what I did was to commit a change to a new branch, forget I was in that branch and committed another unrelated change which should have gone back to trunk but went into the branch. I then attempted to change that latest commit by adding a 'trunk' tag and cancelling the new branch tag. I'm pretty sure that was wrong, but I'm unsure now where to go with this. I've tried a few other things to no avail, but now even after executing 'fossil update trunk' the 'fossil branch' command shows I'm still in the new branch. So I have two problems to solve: 1) how do I properly move commits between branches (and to trunk, in my case)? 2) how do I unfudge my current condition and get back to trunk? ___ 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] `unversioned' questions
Hi,
On 26/06/18 13:22, j. van den hoff wrote:
> On Tue, 26 Jun 2018 18:58:42 +0200, Andy Goth
> wrote:
>
>> I think the next project that needs this feature should write a
>> utility script for themselves that uses the uv commands to extract
>> files however makes sense for them. This live experimentation is
>> necessary to figure what is needed in practice. No one is forced to
>> wait for any changes to be made to Fossil itself. One day, a set of
>> best practices (i.e., a vague consensus on which compromises and
>> heuristics most people can live with most of the time) will emerge,
>> at which point Fossil can adopt them as useful defaults, but people
>> should always be able to write new scripts that work best for their
>> specific projects.
>>
>> On 06/26/18 10:31, Richard Hipp wrote:
>>> My thought was to provide a new setting (perhaps versionable) that
>>> specified a directory relative to the root of the check-out into which
>>> unversioned files are written whenever one does "fossil update" or
>>> "fossil checkout". If the setting is missing or empty, then Fossil
>>> works as it does now. If you turn on the setting, though, then the
>>> unversioned files work just like other files in the check-out, except
>>> that Fossil never records their history.
>>
>> I overall like the idea, but I can envision an endless stream of
>> feature creep as people want to do any of the following and more:
>>
>> - Deal with files having platform-incompatible names (slashes,
>> backslashes, drive letters, characters unsupported by the filesystem)
>> - Extract only files within certain size ranges
>> - Extract only files within certain date ranges
>> - Extract only files matching certain glob patterns
>> - Update the unversioned files when checking in
>> - Get diffs showing which unversioned files have changed
>> - Handle new files being added to the unversioned directory
>> - Reverse filename mapping done for platform compatibility when
>> checking in or adding new unversioned files
>> - Selectively check in unversioned files along with the rest of the
>> check-in
>>
>> And on it goes. All of the above can be done today via shell
>> scripts, so projects wanting to experiment are invited to get started
>> right away.
>
> I dislike feature creep and endless "please implement this for me"
> requests, too. but I don't think this argument applies here, really.
> anyway the developer(s) decide what they implement and what not...
>
> from this thread I have learned in the meantime, that uv-files where
> intended for something different than what I would have guessed
> ("created for the purpose of providing a place to store build products
> when Fossil is used as a server") and that uv-files usually(is that
> right?) are residing outside of the checkout. so be it. and then I can
> understand why fossil does what it does with uv-files (and what it
> does not, namely providing a `fsl uv up' command that would do the
> same with uv-files that `fsl up' does with versioned files.
>
> all the possible issues with file system /OS issues etc. are sure
> valid but to the extent that fossil handles these with versioned files
> it could do the same with uv-files (at least as long as their
> pathnames are relative to the checkout root).
>
> so my question would be:
>
> is their any strong argument against a `fossil up -u' command? would
> it be undesirable to have? (if it really is going to be implemented
> und whether drh is willing to invest the time is a different question,
> naturally.) I think it would be quite valuable for assorted projects,
> notably those depending on large binary files such as jpeg-images (or
> libs) that are *project-specific* and prone to multiple changes over
> the duration of the project but where tracking changes of these files
> is not required. I simply would find it useful to be able to do `fsl
> up; fsl up -u' (or both with a single command) in order to bring my
> checkout including uv-files up to date...
>
> and yes, I will write a shell or TCL script to do this, if everything
> else fails. but it will be inferior to integration of this feature
> into fossil.
>
I'm using Fossil in this precise context for storing inside a repository
a large PDF file that is produced from LaTeX source files. What is most
surprising to me, is the fact that I need to add again the unversioned
file *every time* before I want to do `fossil uv -v` to update such file
in the repository.
So, I'm pretty interested in this thread and the solutions and
suggestions that you arrive. Using Fossil as a DVCS for reproducible
documentation, research and publishing is the exact case you're
advocating for and the features for least surprise regarding unversioned
files inside the repository are pretty pertinent there.
Cheers,
Offray
___
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] `unversioned' questions
Hi, I share J. approach on this. Unversioned files, *when* used inside a repo, containing relative paths should provide more automatization, for example, when making some sync or cloning. Of course, you may not want to sync each unversioned file each time (for example when large PDFs are unversioned files in the repository), but having to add them, *each time* before making any sync seems counter intuitive. `fossil uv sync -v` should, in some setting, allow such automatic behavior without previous `fossil uv add path/to/the-same-file` each time we want to resync unversioned files already in the repo. Cheers, Offray On 26/06/18 11:48, j. van den hoff wrote: > On Tue, 26 Jun 2018 18:33:22 +0200, Stephan Beal > wrote: > >> On Tue, Jun 26, 2018 at 5:45 PM wrote: >> >>> Can unversioned files respect their original paths when added? >>> I have several locations for bitmaps, icons, pdf's, etc. >>> They do not necessarily reside in an isolated folder. > > yes, same here, *but* in directories *within* the checkout dir. > >>> >> >> That wouldn't work cross-platform. You might store file the C:\D\e\f.txt >> >> which i could not extract on Unix because we don't have drive >> letters. If >> we ignore the C: part, i still couldn't extract to /D/e/f.txt, unless >> i was >> the root user. Case sensitivity is another problem in that regard. If >> you >> store C:\D\e.txt and C:\d\e.txt, those would map to two different >> folders >> on Unix systems. >> >> Likewise, Unix /a/b/c.txt has no direct mapping on Windows (which drive >> should it use?). > > I was only thinking about *relative* pathnames w.r.t. checkout root > and that sure could be managed with the same logic cross-plattform as > versioned files, right? > > but as explained, I have not used uv-files until today (and have not > followed the discussion closely, when it was implemented). so I do not > know all the use cases that are of relevance here. > > I now -- in view of your mail -- understand of course that there could > be use cases (possibly the majority) where uv-files are located > somewhere else in the file tree, rather than in the checkout. no idea > how these should be properly handled, than. probably the way DRH just > proposed would than be the only way. > > o.t.o.h.: the special case, where *everything* (versioned and > unversioned files) reside together in the checkout dir might deserve > special consideration/handling. it seems to me the "logical" > extension/next step beyond "put everything under revision control": > still keep all the stuff that constitutes "the project" together in > one place (the checkout dir), but decide which files could be handled > as uv-files in order to safe on disk space/repo size. > > this would imply special handling of the case "`fossil uv ls'" reports > relative, rather than absolute pathnames" but maybe it could be quite > useful, just think of my simple example: a LaTeX doc including several > project-specific image files that I do not want to keep under revision > control but as part of the repo. the tex-file will no longer compile > on "the other side" if the uv-files are not put back into the expected > (relative) location... > >> > > ___ 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] [minor] src/style.c:427 → "%
On Jul 2, 2018, at 9:38 PM, David Mason wrote: > > It's pretty common to put classes on tags, to use CSS to conditionally > choose different renderings by simply changing the class of the body tag. I think you’d have to write TH1 code to get Fossil to serve more than one tag on a given repository. That then makes me wonder if that would be another way to trick Fossil into serving a second tag. Consider this pseudocode: return [concat ""] I say “pseudocode” because it’s probably horrid Tcl style, if it compiles at all. I speak only pidgin Tcl these days. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
