Dear Devs

It would be absolutely fantastic if there can (or is that I am overlooking) be a option to set the checkin times to the file times when adding files, especially for creating new fossil repositories from old development and other directories...

With 2.9 this was done: Added the fossil touch command, and the --setmtime option on the fossil open and fossil update commands. which I for one VERY MUCH APPRECIATED!!

Plz plz plz Andre

The 2.9 features you mention operate on checked out files, which is quite different from altering the commit timeline.

If you perform a checkin with two files with this option enabled, and one has a timestamp of two minutes ago and one has a timestamp of a week ago, what do you propose should happen?

If you really need a fake commit timeline, consider instead writing a script that changes the system clock and checks in each file one at a time (or do it manually).

Fossil does not record file timestamps. It only records commit timestamps, and treats all files modified by the same commit as having the same timestamp. Fossil's definition of a file's timestamp is essentially the time of the newest commit in which that file was modified.

Have you seen the --date-override option on the "fossil commit" command?

The 2.9 features allows creating a standalone directories showing last edited times - perfect for plain archives and visual interpretation by users not working with Fossil.

It will be used to add actual files with actual last edited/creation times. Thus 2 minutes or 2 years apart, it is the actual timeline.

Have tried the script thing once on windows and it was really time consuming and error prone etc. Would have really liked it to rather be a standard option like above, in the same executable.

Thanks Andre

And it would be a great help if those commit timestamps can automatically be set to reflect the file time when adding them with a new repository.

It will be actual last modified times.

Thanks Andre

To get the effect you're looking for requires making a separate commit for each file, using -date-override. Fossil has no mechanism/infrastructure to manipulate the SCM-side timestamps of individual files, only whole commits.

But cant a option be added just to read the file time and use that instead of what is specified with -date-override so that for example the following can be done:

fossil ci --date-get-and-use-file-date ...

That way new repositories from historic or other populated directories can easily be created with actual/realistic checkin times.

i don't think that would behave how you would like it to:

1. That would effectively set the timestamp of all files in the commit to that one time. (Fossil has no mechanism for storing file times for individual files.)

2. Fossil would still need to be told which file to use for the timestamp (because the source files may have different times). Because of that, there's really no convenience over using --date-override.

We could potentially add an option which works like --date-override but accepts a filename, and uses the timestamp from that file in the same way which --date-override would be applied:

fossil com -m ... --date-override-from-file myfile ...

Ok I think I'm getting it...

Your potential option would already be a big step forward in my case.

The ideal for me would have been if Fossil can add the files/directories recursively and committing each file as it goes with the file's date.

Thanks anyway for taking the time to discuss and teach me more about Fossil!! Andre

The ideal for me would have been if Fossil can add the files/directories recursively and committing each file as it goes with the file's date.

That would require doing a separate commit for each and every file, using -date-override for every one. The end result would be an arbitrarily large number of commits and the timeline would be a massive ball of spaghetti lines because of the timestamps being overridden in an arbitrary order. The resulting timeline and project history would almost certainly be effectively unusable.

IMO such an unusual use case falls clearly in the realm of a script which would be unlikely to be used more than once because of the mess it would make of the project history.

The ideal for me would have been if Fossil can add the files/directories recursively and committing each file as it goes with the file's date.

As in this script?

#!/bin/bash

function addone () {
  echo fossil add $2
  echo fossil commit --date-override $1 -m "Added $2 with timestamp $1"
}

## MAIN ##

if [ "$1" == "addone" ]
then
  addone $2 $3
else
  find . -type f -printf '%TY-%Tm-%TdT%TH:%TM:%TS %p\n' \
  |grep -vE '(/tmp|/var/)' \
  |awk '{print substr($1,1,19),substr($2,3)}' \
  |sort -k1,1 \
  |xargs -n 2 $0 addone
fi

Untested. Remove the echo commands in the addone function to make it do real work.

Regards,

Kees Nuyt

I unfortunately dont have bash expertise but it looks like you did the expert thing of what I tried with a windows batch file:

Copy all files into a batch file and then modified it to

• Set system time from file time
• Add
• Commit
• loop through all files.

I tried to devise something for my wife whom is a lecturer in auditing and trying to simulate something over 2 year projects with students. At the end of the 1st year students would have created the Fossil repository and hand it in. The 2nd year consists of normal file edits and maybe a few additions throughout the year, adding and committing. So unfortunately all my attempts with scripts etc. just won't work with the students, different computers and most likely full of errors.

Sorry for not being clear of my intentions in the first place.

Thanks to all!!

Andre

"That would require doing a separate commit for each and every file, using -date-override for every one." The end result would be an arbitrarily large number of commits"

One per file.

"and the timeline would be a massive ball of spaghetti lines because of the timestamps being overridden in an arbitrary order. The resulting timeline and project history would almost certainly be effectively unusable."

Not at all as it will reflect actual and true file creation / last updated times at time of Fossil repository creation.

Thanks Andre

Not at all as it will reflect actual and true file creation / last updated times at time of Fossil repository creation.

Yes, but fossil's history is not file-based, it's commit-based. As an example, i took the script posted above, tweaked it a tiny bit to get it running, and ran it on a copy of the fossil source tree. The resulting repository now has 643 commits and a timeline which contains constructs like:

https://wanderinghorse.net/tmp/fossil-checkin-one-file-at-a-time.png

The timeline renderer outright fails (doesn't draw anything) if told to render 100 items (or all items) in the timeline, presumably because the connections are so crazy.

i just checked, and git also doesn't store file timestamps - it stores the time of the change, like fossil does.

For completeness's sake, the modified script:

#!/bin/bash

function addone () {
  fossil add "$2" && fossil commit --date-override --no-warnings --allow-older "$1" -m "Added $2 with timestamp $1"
}

## MAIN ##

if [ "$1" == "addone" ]
then
  addone "$2" "$3"
else
  find . -type f -printf '%TY-%Tm-%TdT%TH:%TM:%TS %p\n' \
  |grep -vE '(/tmp|/var/)' \
  |awk '{print substr($1,1,19),substr($2,3)}' \
  |sort -k1,1 \
  |xargs -n 2 "$0" addone
fi

The --no-warnings flag was needed for files with "long lines" and --allow-older was needed for checking in a new version which is older than its parent.

So if I'm not mistaken all that is needed to prevent those strange constructs would be if there was a way to pre-sort all files by date before adding/committing.

I'll think about it, perhaps get someone to write me a seperate executable that can sort the files and then do the Fossil thing with each file.

Even though the history is not file based it would have been of much help to me anyway to be able to do the reverse of what was added in 2.9 with the touch command etc.

(Git is a no go anyway for these students.)

Andre

I'll think about it, perhaps get someone to write me a seperate executable that can sort the files and then do the Fossil thing with each file.

A script which can do that, whether it's in perl or python or PowerShell, is certainly the way to go. Sort the files by timestamp and then check them in from oldest to newest. As an additional touch (no pun intended), first change the timestamp of the "initial empty checkin" to be older than the first file, using something like:

fossil amend --date THE_TIMESTAMP tip

When run on a new/empty repository, the version name tip will resolve to the initial checkin. (rid:1 would also hypothetically always work, but it's not guaranteed to.)

Use a timestamp of YYYY-MM-DD to set the time to midnight of that day, or (with a bit more code) use YYYY-MM-DDThh:mm:ss to set it to 1 second older than the oldest file.

Ideally the initial checkin's time would be modified before adding any files, as that would eliminate the need for the --allow-older checkin flag. (It's not critical, just a cosmetic detail.) Whether it's set before or after importing everything isn't all that important, but it should be modified at some point to predate the first file, so that the timeline page can Do The Right Thing vis-a-vis drawing all of the arrows in the intended direction.

(Git is a no go anyway for these students.)

LOL - as it is for many of us :).

I wrote a similar script to convert a series of release tarballs to Fossil check-ins in order to reconstruct the partial history of a project from the releases. (I lost access to the VCS and so only had the release tarballs to work from.)

It has a number of neat features:

• You can feed it a tb-ignore-glob file to make it not check certain files into the repo. For example, an Autotools based project will ship a "configure" script, but you don't want to check that into a VCS, only the "configure.ac" input file that it's generated from.

• It automatically generates check-in messages from tarball file name contents.

• Its method of finding the timestamp from the newest file in the working tree should work for the OP's purpose. That is to say, we don't get the timestamp from the tarball file itself, but from its file contents.

The ggrep, gsort, and gtar commands are for the GNU versions of the tools without the "g" prefix, which I needed on the macOS box I wrote this on, since this script doesn't work with the BSD versions of these tools. If you're on a system that uses the GNU tools as its defaults — Linux, Cygwin, etc. — you can drop the prefix.

Thank you again for taking the time to discuss, tips etc.

I might just get somewhere, even if not what was my ideal reuirement.

Andre

Thank you also for lookinng at it and posting this. It will most definately be of help!

Andre