On 3/13/15, Andy Bradford wrote:
>
> So while Fossil 1.27 did successfully add the content (no content was
> lost) it picked the wrong file to generate the P-card.
>
> I don't know of any way to repair this.
>
There is a "parent" tag set aside for this purpose
(https://www.fossil-scm.org/
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 t
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
On Fri, Mar 13, 2015 at 10:59:26AM +0100, Jan Nijtmans wrote:
> 2015-03-13 8:49 GMT+01:00 Stephan Beal :
> > 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
On 13 March 2015 at 05:59, Jan Nijtmans wrote:
> I read in this thread) with Richard's conclusion that work has been lost
> due to fossil, but David Mason should have the final word on that (the
> DELETE's in David's original story meant that those _unchanged_ files
> were removed from the working
On Fri, Mar 13, 2015 at 1:12 PM, Tontyna 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 a form which the db
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 magically
2015-03-13 8:49 GMT+01:00 Stephan Beal :
> 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 should never h
On Fri, Mar 13, 2015 at 12:18 AM, Tontyna 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 earlier that he
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 loc
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 1
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 instr
On 3/12/15, David Mason 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 introduced ch
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 wrote:
> On 3/12
On 3/12/15, Jan Nijtmans 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 changes that allow
2015-03-12 15:22 GMT+01:00 Richard Hipp :
> 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 <1.30 had
b
On 3/12/15, David Mason 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
> are very
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, Tont
On 3/12/15, Tontyna 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
>> the resour
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 imagine
On 3/11/15, David Mason 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 .fossil-settings
On Wed, Mar 11, 2015 at 8:25 AM, Richard Hipp wrote:
> On 3/11/15, David Mason 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 merge says there's no h
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 th
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
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 e
On 3/11/15, Andy Bradford 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 should have happen
On 3/11/15, Andy Bradford 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). I would virtual
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 stu
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 initializ
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 wrote:
> Thus said Richard H
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 I
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
On Wed, Mar 11, 2015 at 11:43 AM, Eric Rubin-Smith 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 we wer
... 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
On 3/11/15, David Mason 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 lot like this
On 3/11/15, Eric Rubin-Smith 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 init"
> 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
fossil-users@lists.fo
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
D
On 3/11/15, Andreas Kupries wrote:
> On Wed, Mar 11, 2015 at 8:25 AM, Richard Hipp wrote:
>> On 3/11/15, David Mason 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 me
On 3/11/15, David Mason 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 the repository in
41 matches
Mail list logo
