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 .fossil-settings/binary-glob
> DELETE .fossil-settings/clean-glob
> DELETE .fossil-settings/ignore-glob
> DELETE .fossil-settings/ignore-glob.no-warn
> DELETE a1/.hold
> DELETE a2/.hold
> DELETE a3/.hold
> DELETE a4/.hold
> DELETE a5/.hold
> DELETE a6/.hold
Maybe this:
fossil up 33f9
fossil merge --baseline 198f28 094b
That gives:
ADDED Fossils/A3.hs
ADDED Fossils/a2-a2.hs
>
> 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 problem. I
> guess they were never working on trunk. Perhaps if i'd told them to
> "fossil update trunk" it would have worked.
That should have been automatic when they first checked out the repo.
>
> 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:
> http://cps506.sarg.ryerson.ca/Resources/fossil.html
1.27 should be completely compatible. It lacks some of the newer
features, but should interoperate just fine.
Are you sure your students didn't "shun" something or try to use "reconstruct"?
>
> ../Dave
>
> On 11 March 2015 at 12:48, Richard Hipp <d...@sqlite.org> wrote:
>> 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 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 them as such doesn't seem to help. Using
>>>>> --baseline in merge didn't help either.
>>>>
>>>> I was about to suggest using --baseline. What is the exact
>>>> command-sequence that you used? And how do you know it didn't work -
>>>> did it give an error?
>>>
>>> I wonder if merging by exact sha-hash would work ?
>>>
>>
>> I'm looking at the source code, and I'm thinking that --baseline ought
>> to work. The command sequence should be:
>>
>> fossil update 33f9c5915f
>> fossil merge 094b1b8a4d --baseline ce53290262
>>
>> I'm still curious as to how the students managed to get the repo into
>> this state, too. The only thing I can think of is that they had one
>> or more check-ins in between ce53290262 and 198f28add5 that the
>> shunned. It makes me wonder if we ought not put more safety checks
>> and harsher warnings on the "shun" command?
>>
>> --
>> 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
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
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
