On Fri, Mar 13, 2015 at 12:18 AM, Tontyna tont...@ultrareal.de wrote:
To reproduce Dave's timeline I was happy to still get Fossil 1.27 from the
download page, but --- I think Fossil 1.30 should be removed from there
or at least be tagged as don't use it with newer repos.
Richard mentioned
2015-03-13 8:49 GMT+01:00 Stephan Beal sgb...@googlemail.com:
Richard mentioned earlier that he will remove the no initial commit bits,
which will (theoretically, at least) eliminate this problem for future
versions. i would hate to see it go
+1
(not enough to raise a fuss about it),
but it
On Fri, Mar 13, 2015 at 1:12 PM, Tontyna tont...@ultrareal.de wrote:
A tricky SQL statement could probably create the required records...
Nope - the db is basically just a transient cache for the manifest
(checkin) data and blobs (file content). The checkin data _is_ also in the
db, but not in
Am 13.03.2015 um 10:59 schrieb Jan Nijtmans:
If the initial commit contains files, Fossil 1.27 doesn't see that, and nothing
reveals they are really there. Therefore, those files look as they have been
lost, but they really aren't: just upgrade to Fossil 1.28 or later and the files
will
On Fri, Mar 13, 2015 at 11:53:10AM -0400, Martin Gagnon wrote:
BTW, chiselapp.com still use version 1.25 release. The same problem
could happens easily when using the Clone Repository option if the
source repo is created without initial empty check-in.
Sorry.. I just notice that it really
On Fri, Mar 13, 2015 at 10:59:26AM +0100, Jan Nijtmans wrote:
2015-03-13 8:49 GMT+01:00 Stephan Beal sgb...@googlemail.com:
Richard mentioned earlier that he will remove the no initial commit bits,
which will (theoretically, at least) eliminate this problem for future
versions. i would hate
Thus said Tontyna on Fri, 13 Mar 2015 13:12:25 +0100:
A tricky SQL statement could probably create the required records...
While no content was lost, the relationship appears to have been lost,
which is why the timeline cannot figure out how to draw it.
Specifically, the problem appears
On 3/11/15, David Mason dma...@ryerson.ca wrote:
I've emailed the fossil to drh.
That sequence of update and merge just toggled between timelines. I.e.:
ADDED Fossils/A3.hs
ADDED Fossils/a1.hs
ADDED Fossils/a2-a2.hs
ADDED Fossils/test
DELETE .fossil-settings/allow-symlinks
DELETE
Am 11.03.2015 um 18:48 schrieb David Mason:
The problem was that the version of fossil that apt-get used was
version 1.27 (I think... maybe 1.29) and I created the fossils with
1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is
the resource page I point them at:
Can't
On 3/12/15, Tontyna tont...@ultrareal.de wrote:
Am 11.03.2015 um 18:48 schrieb David Mason:
The problem was that the version of fossil that apt-get used was
version 1.27 (I think... maybe 1.29) and I created the fossils with
1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is
On 3/12/15, David Mason dma...@ryerson.ca wrote:
Thanks Tontyna!
I was going to do what you tried, today, but I really appreciate you
confirming it.
It is certainly possible that the students would do a fossil rebuild
if fossil told them to. The odds of 20 of them doing that if not told
On 3/12/15, Jan Nijtmans jan.nijtm...@gmail.com wrote:
Much better, preventing the problem all together: create the
repository with Fossil 1.27 to begin with. Fossil 1.30 had
bugs which ill-treat repositories without any commits. Those
were fixed in Fossil 1.30.
Just to be clear: Those
Thanks Tontyna!
I was going to do what you tried, today, but I really appreciate you
confirming it.
It is certainly possible that the students would do a fossil rebuild
if fossil told them to. The odds of 20 of them doing that if not told
are very low.
../Dave
On 12 March 2015 at 06:40,
2015-03-12 15:22 GMT+01:00 Richard Hipp d...@sqlite.org:
The fossil rebuild is not necessary. All they have to do is use
Fossil 1.27 to clone a repo that was created with Fossil 1.30.
Much better, preventing the problem all together: create the
repository with Fossil 1.27 to begin with. Fossil
The repository provided to the students *did* have commits:
.fossil-settings with 4+ files and 6 directories with .hold files in
them. But maybe what you're saying is that something post-1.27 to
support that caused other problems.
../Dave
On 12 March 2015 at 10:34, Richard Hipp d...@sqlite.org
Thus said Tontyna on Thu, 12 Mar 2015 11:40:32 +0100:
1. Created a repo with Fossil 1.30
2. Switched to Fossil 1.27
3. clone/open worked without warning
BTW: open produced a _FOSSIL_ but the local reposirory was empty,
i.e no checked-out files at all
According to David's
On 3/12/15, David Mason dma...@ryerson.ca wrote:
The repository provided to the students *did* have commits:
.fossil-settings with 4+ files and 6 directories with .hold files in
them. But maybe what you're saying is that something post-1.27 to
support that caused other problems.
Version 1.29
No I copied the script that creates the fossils directly into that
email, and apart from the warning in red, the instructions to students
are unchanged. The odd student might do something different, but most
will have done only and exactly what the instructions say.
../Dave
On 12 March 2015 at
Am 12.03.2015 um 18:25 schrieb Andy Bradford:
Thus said Tontyna on Thu, 12 Mar 2015 11:40:32 +0100:
1. Created a repo with Fossil 1.30
forgot to mention: added a file and committed
2. Switched to Fossil 1.27
3. clone/open worked without warning
BTW: open produced a _FOSSIL_ but the
I have several students who, through some problem while cloning the
fossil I created for them, created a parallel timeline. (see
screenshot)
I want to merge them, but fossil merge says there's no head to merge.
The commits by the student are on the right and are not tagged as
trunk, but tagging
On Wed, Mar 11, 2015 at 8:25 AM, Richard Hipp d...@sqlite.org wrote:
On 3/11/15, David Mason dma...@ryerson.ca wrote:
I have several students who, through some problem while cloning the
fossil I created for them, created a parallel timeline. (see
screenshot)
I want to merge them, but fossil
On 3/11/15, Andreas Kupries andre...@activestate.com wrote:
On Wed, Mar 11, 2015 at 8:25 AM, Richard Hipp d...@sqlite.org wrote:
On 3/11/15, David Mason dma...@ryerson.ca wrote:
I have several students who, through some problem while cloning the
fossil I created for them, created a parallel
On 3/11/15, David Mason dma...@ryerson.ca wrote:
I have several students who, through some problem while cloning the
fossil I created for them, created a parallel timeline. (see
screenshot)
Fossil is suppose to be bullet-proof. I'd really like to know what
your students did in order to get
Thus said Richard Hipp on Wed, 11 Mar 2015 15:56:41 -0400:
That's an processing artifact of the graph generator. The 198f28add5
check-in references some parent a09a968bf05 which is not in the tree,
so the graph generator just draws a line off the bottom of the page,
not knowing what else
Thanks for all the imagining. (Sorry, I was off reading the latest
episode of Harry Potter and the Methods of Rationality hpmor.com
quite extraordinary!)
But I'm back. I could imagine one student doing some weird thing, but
not a score of them with the same outcome. The directions were as
On 3/11/15, Andy Bradford amb-fos...@bradfords.org wrote:
We're just eliminating all the obvious things. So, let me ask this... in
the PNG of the timeline you sent, why does your ``default setup'' commit
show up *after* the other timeline's first commit?
According to your own steps, this
On 3/11/15, David Mason dma...@ryerson.ca wrote:
As for what they did, it was a while ago that they set them up. There
was a problem that the students on Linux (typically ubuntu) didn't see
the stuff I had created for them (default .fossil-settings and
assignment directories), which sounds a
Are you sure your students didn't shun something or try to use
reconstruct?
What would happen if the student tried to push a repo that they had created
with 'fossil init' to the central clone?
___
fossil-users mailing list
On Wed, Mar 11, 2015 at 11:43 AM, Eric Rubin-Smith eas@gmail.com wrote:
... unless the students used raw SQL to hack there project-id to make
it match the repository into which they were pushing. But I'm
thinking that is not what happened here.
Little anecdote. When I was a student
Thus said David Mason on Wed, 11 Mar 2015 15:17:57 -0400:
But I'm back. I could imagine one student doing some weird thing, but
not a score of them with the same outcome. The directions were as I
posted (without the bits in red). I would virtually guarantee that
*none* of the
On 3/11/15, Eric Rubin-Smith eas@gmail.com wrote:
Are you sure your students didn't shun something or try to use
reconstruct?
What would happen if the student tried to push a repo that they had created
with 'fossil init' to the central clone?
The push would be refused. Every fossil
... unless the students used raw SQL to hack there project-id to make
it match the repository into which they were pushing. But I'm
thinking that is not what happened here.
Little anecdote. When I was a student we were using CVS for our big
project. One teammate couldn't understand why his
Thus said Richard Hipp on Wed, 11 Mar 2015 12:48:04 -0400:
I'm still curious as to how the students managed to get the repo into
this state, too.
This is possible if you open a repository using the --empty command line
option. Basically, what you end up with when you do this are two DAGs in
Thus said David Mason on Wed, 11 Mar 2015 11:07:11 -0400:
I have several students who, through some problem while cloning
the fossil I created for them, created a parallel timeline. (see
screenshot)
Do you create the intial repository for the students?
If so, do you initialize
I've emailed the fossil to drh.
That sequence of update and merge just toggled between timelines. I.e.:
ADDED Fossils/A3.hs
ADDED Fossils/a1.hs
ADDED Fossils/a2-a2.hs
ADDED Fossils/test
DELETE .fossil-settings/allow-symlinks
DELETE .fossil-settings/binary-glob
DELETE .fossil-settings/clean-glob
I'd virtually guarantee that 20 students - and only the ones running
using the apt-get fossil - did not try the --empty switch.
Unfortunately.
And when I added tags to the empty timeline they were still not mergable.
../Dave
On 11 March 2015 at 15:10, Andy Bradford amb-fos...@bradfords.org
On 3/11/15, Andy Bradford amb-fos...@bradfords.org wrote:
Thus said David Mason on Wed, 11 Mar 2015 15:17:57 -0400:
But I'm back. I could imagine one student doing some weird thing, but
not a score of them with the same outcome. The directions were as I
posted (without the bits in red).
Thus said David Mason on Wed, 11 Mar 2015 15:17:57 -0400:
Does that help at all?
I tried these steps with Fossil from trunk and saw the files when I
opened the Fossil. Any chance you could make up a test fossil using
the above mentioned steps (and a fake student/user and TA) in
Thus said Richard Hipp on Wed, 11 Mar 2015 14:32:18 -0400:
Brainstorming... Maybe something like this occurred:
(1) Copy the original repository file into xyz.fossil
(2) run fossil open xyz.fossil
(3) Copy a revised version of the repository over top of xyz.fossil
(4) run
39 matches
Mail list logo
