FileDoesNotExist error when merging and directory had a .prefix?

[macta]

Just when to push some changes on a branch to origin, I was prompted to do a merge (correct, as I had made some changes on another computer and pushed them into that branch - specifically I added some data files in a directory called /exercises/hello-world/.meta/TestFile.class.st).

I got a walkback after the prompt saying this file didn't exist (it was supposed to be merging it?).

walkback below - the reference streamError was: File @ /Users/macta/Dev/Smalltalk/Pharo/Pharo 6.1 - 64bit (tech preview)-ExercismDev/pharo-local/iceberg/exercism/pharo/exercises/hello-world/.meta/solution/HelloWorld.class.st

FileHandle>>streamError FileHandle>>writeStream FileSystem>>writeStreamOn: FileReference>>binaryWriteStream FileReference(AbstractFileReference)>>binaryWriteStreamDo: IceGitWorkingCopyUpdateVisitor>>visitFileNode: IceFileDefinition>>accept: IceGitWorkingCopyUpdateVisitor>>visitAddition: IceAddition>>accept: IceGitWorkingCopyUpdateVisitor>>visitNonConflictingOperation: IceNonConflictingOperation>>accept: [ anIceNode value accept: self ] in IceGitWorkingCopyUpdateVisitor(IceTreeVisitor)>>visitTreeNode: in Block: [ anIceNode value accept: self ] BlockClosure>>ensure: IceGitWorkingCopyUpdateVisitor(IceTreeVisitor)>>withNode:do: IceGitWorkingCopyUpdateVisitor(IceTreeVisitor)>>visitTreeNode: IceNode>>accept: [ :each | each accept: self ] in IceGitWorkingCopyUpdateVisitor(IceTreeVisitor)>>visitChildrenOf: in Block: [ :each | each accept: self ] Array(SequenceableCollection)>>do: IceNode>>childrenDo: IceGitWorkingCopyUpdateVisitor(IceTreeVisitor)>>visitChildrenOf: IceGitWorkingCopyUpdateVisitor>>visitDirectoryDefinition: IceDirectoryDefinition>>accept: IceGitWorkingCopyUpdateVisitor>>visitNoModification: IceNoModification>>accept: IceGitWorkingCopyUpdateVisitor>>visitNonConflictingOperation: IceNonConflictingOperation>>accept: [ anIceNode value accept: self ] in IceGitWorkingCopyUpdateVisitor(IceTreeVisitor)>>visitTreeNode: in Block: [ anIceNode value accept: self ] BlockClosure>>ensure: IceGitWorkingCopyUpdateVisitor(IceTreeVisitor)>>withNode:do: IceGitWorkingCopyUpdateVisitor(IceTreeVisitor)>>visitTreeNode:

[macta]

If I close the debugger and then try to do a pull myself - I get another walkback: below didn't implement mergeCommit:

IceInMergeWorkingCopy(Object)>>subclassResponsibility IceInMergeWorkingCopy(IceWorkingCopyState)>>mergeCommit: IceWorkingCopy>>mergeCommit: IceGitLocalBranch(IceLocalBranch)>>pullFrom: IceLibgitRepository(IceRepository)>>pullFrom: [ self entity pullFrom: self remote ] in IceTipPullModel>>pullThen: in Block: [ self entity pullFrom: self remote ] [ :bar | bar label: aString. aBlock value ] in MorphicUIManager(UIManager)>>informUser:during: in Block: [ :bar | ... [ :bar | aBlock value: bar ] in MorphicUIManager>>informUserDuring: in Block: [ :bar | aBlock value: bar ] BlockClosure>>cull: [ ^ block cull: self ] in [ self prepareForRunning. CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in Block: [ ^ block cull: self ] [ activeProcess psValueAt: index put: anObject. aBlock value ] in CurrentJob(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: CurrentJob(DynamicVariable)>>value:during: CurrentJob class(DynamicVariable class)>>value:during: [ self prepareForRunning. CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in Block: [ self prepareForRunning.... BlockClosure>>ensure: Job>>run MorphicUIManager(UIManager)>>displayProgress:from:to:during: MorphicUIManager>>informUserDuring: MorphicUIManager(UIManager)>>informUser:during: IceTipStandardAction>>basicExecute [ self basicExecute. self finishSuccess ] in IceTipStandardAction(IceTipAction)>>execute in Block: [ self basicExecute.... BlockClosure>>on:do: IceTipStandardAction(IceTipAction)>>withErrorHandlingDo: IceTipStandardAction(IceTipAction)>>execute IceTipStandardAction>>execute: IceTipPullModel>>pullThen: IceTipCachedModel>>forwardMessage: IceTipCachedModel>>doesNotUnderstand: #pullThen: IceTipPullBrowser>>doPull

[macta]

My image is now struggling - I can't even checkout another branch or open iceberg as I now get:

because - aToolContext repositoryModel entity workingCopy referenceCommit gives an array which contains 2 IceGitCommit objects.

Array(Object)>>doesNotUnderstand: #isUnknownCommit IceTipDiscardChangesCommand class>>canBeExecutedInContext: IceTipWorkingCopyContext(CmdToolContext)>>allowsExecutionOf: IceTipToolbarActivation(CmdCommandActivationStrategy)>>isActiveInContext: CmdCommandActivator>>canExecuteCommand [ :each | each activator canExecuteCommand ] in CmdRootMenuGroup>>buildIceToolbarOn: in Block: [ :each | each activator canExecuteCommand ] SortedCollection(SequenceableCollection)>>select:thenDo: CmdRootMenuGroup>>buildIceToolbarOn: CmdMenu>>buildIceToolbarOn: IceTipToolbar>>addItemsFromContext: IceTipWorkingCopyBrowser(IceTipBrowser)>>rebuildToolbar IceTipWorkingCopyBrowser(IceTipBrowser)>>initializeToolbar IceTipWorkingCopyBrowser(IceTipBrowser)>>initializeWidgets IceTipWorkingCopyBrowser>>initializeWidgets IceTipWorkingCopyBrowser(ComposableModel)>>initialize IceTipWorkingCopyBrowser(IceTipBrowser)>>initialize IceTipWorkingCopyBrowser class(ComposableModel class)>>on: IceTipManagePackagesCommand>>execute IceTipRepositoryListContext(CmdToolContext)>>executeCommand:by: [ self prepareCommandForExecution. context executeCommand: command by: self. self applyCommandResult ] in CmdCommandActivator>>executeCommand in Block: [ self prepareCommandForExecution.... BlockClosure>>on:do: CmdCommandActivator>>executeCommand [ :each | each executeCommand ] in IceTipRepositoriesBrowser>>repositoryStrongSelection: in Block: [ :each | each executeCommand ] [ :activationStrategy | blockWithActivator value: (activationStrategy newActivatorFor: aToolContext) ] in IceTipCommandStrongSelectionActivation class(CmdCommandActivationStrategy class)>>activateAllInContext:by: in Block: [ :activationStrategy | ... SortedCollection(SequenceableCollection)>>select:thenDo: IceTipCommandStrongSelectionActivation class(ClassAnnotation class)>>activeInstancesInContext:do: IceTipCommandStrongSelectionActivation class(CmdCommandActivationStrategy class)>>activateAllInContext:by: IceTipRepositoriesBrowser>>repositoryStrongSelection: MessageSend>>value: MessageSend>>cull:

[macta]

luckily I was able to do the pull/merge/push on the command line so no code lost

[guillep]

If you could tell me exactly the two commits commits that you were merging (or tell me the merge commit to extract that info) I should be able to reproduce it 100% sure :). And then I'll build a test from it.

On Mon, Aug 6, 2018 at 11:46 PM Tim Mackinnon notifications@github.com wrote:

luckily I was able to do the pull/merge/push on the command line so no code lost

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pharo-vcs/iceberg/issues/959#issuecomment-410863177, or mute the thread https://github.com/notifications/unsubscribe-auth/AArO4u7hooEOBvynCmtSWZjp1xf9QoiOks5uOLlFgaJpZM4VxHEn .

--

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr http://www.cnrs.fr

Web: http://guillep.github.io http://guillep.github.io

Phone: +33 06 52 70 66 13

[macta]

@guillep I kept the image with the error in it - would that help? Otherwise as its a local repo, would you need all of that too? Fortunately its an oss project (exercism) where I've been using iceberg git quite extensively so that data is all publicly available.

I'm happy to help however I can on this, as iceberg is definitely the future particularly for oss projects.

I've been dancing between branches and merrily pushing pr's in two different ide's (pharo and intellij) and its mostly works. So it would be good to help the cause on this.

[guillep]

Actually, just the commits should suffice, because with them I should be able to reproduce the exact same merge :).

Are those commits public? If you just put here the repository url and the commitishes in here that'll be more than enough ^^.

[macta]

When you say commits - what are you referring to - the hash id's? Is there an easy way for me to determine the id's of the commits leading to what happened - I guess I have to look in the history right?

In the broken image - when there is an array of 2 commits it shows: "IceGitCommit(533767dd28ac1f6872f0525e3ef23948722f28e2)" "IceGitCommit(6cd734523f2e03ae2a462f11e70f414f083fcda4)"

The public url of the repository is: https://github.com/exercism/pharo/tree/master/dev/src

I can dig around more to help - and as I said, I have the image in question that launches with the results of the above. I may have the terminal with the git stuff I did (not handy at the moment)

[guillep]

That should already be enough ^^. But first, the "broken working copy" and the merge issue are two different problems. I'd like to focus on the merge problem. If you want to workaround your working copy and fix it, you can just do an adopt on a commit, and that will do it ;).

(repository lookupCommit: 'xxxxx') adopt.

So, focusing on the merge, I've made a script to reproduce the case it in a clean image with latest iceberg.

Metacello new
    githubUser: 'exercism' project: 'pharo' commitish: '533767dd28ac1f6872f0525e3ef23948722f28e2' path: 'dev/src';
    baseline: 'Exercism';
    load.

IceRepository registry last createBranch: 'test'.
(IceRepository registry last lookupCommit: '6cd734523f2e03ae2a462f11e70f414f083fcda4') merge.

I've tried this in Pharo 7.0 32bits, 6.1 32bits and 6.1 64bits. But

• The merge did not raise any conflicts (am I in the right commit?). I only had an "experimental feature warning" because the project was dirty... But that's not the same...
• It merged cleanly, I had no exceptions whatsoever

Now, checking the exception, it looks really odd:

File @ /Users/macta/Dev/Smalltalk/Pharo/Pharo 6.1 - 64bit (tech preview)-ExercismDev/pharo-local/iceberg/exercism/pharo/exercises/hello-world/.meta/solution/HelloWorld.class.st

FileHandle>>streamError
FileHandle>>writeStream
FileSystem>>writeStreamOn:
FileReference>>binaryWriteStream
FileReference(AbstractFileReference)>>binaryWriteStreamDo:
IceGitWorkingCopyUpdateVisitor>>visitFileNode:
IceFileDefinition>>accept:
IceGitWorkingCopyUpdateVisitor>>visitAddition:

I got a walkback after the prompt saying this file didn't exist (it was supposed to be merging it?).

This means that Pharo gave an error while creating the file (because we create it in Pharo during the merge). If we check the code that does that (IceGitWorkingCopyUpdateVisitor>>#visitFileNode:), the method first creates the parent directory of the file and then opens the file for writing... So I do not understand why it did fail. It looks like it is not an iceberg error, there was something else going wrong with your file system or even your image. The only reason I know Pharo wouldn't open a file in a *nix is because of file permissions?

Also, this is the comment of the file open primitive in Pharo6.1:

StandardFileStream>>primOpen: fileName writable: writableFlag
    "Open a file of the given name, and return the file ID obtained.
    If writableFlag is true, then
        if there is none with this name, then create one
        else prepare to overwrite the existing from the beginning
    otherwise
        if the file exists, open it read-only
        else return nil"

    <primitive: 'primitiveFileOpen' module: 'FilePlugin'>
    ^ nil

So I'm puzzled. Were you able to do new merges of that .meta directory after and before this issue? Because also, Iceberg does not do any special handling of dot prefixed files...

[macta]

Hi - already my memory is a bit fuzzy... but here’s what I recall.

I’m running two copies of the repo in different directories. One in Pharo the other in IntelliJ (mostly because Pharo won’t checkin files in other parts of the repo).

Anyway - I have to generate some files for exercism and so I wrote Pharo code to generate those .meta directories with config and examples. I think I pushed the code and then generated the output. Flipped to IntelliJ (in another seperate directory) asjusted a readme and pushed that change. Spotted a bug and in Pharo fixed that and then tried to push and hit this error. When I failed as outlined above - I went to the terminal and was able to pull (but had to specify the branch) and then push (and also specify the branch - git promoted me). Git was happy with all the files in the same directory as Pharo and had no issues. So it was something in Pharo. The only thing that stood out was the .meta in the file name. So not sure why it was unhappy - everything seemed ok, with no obvioys funny things.

I had however switched branches a few times? And it’s an image a few days old with active use.

Having fixed it at the command line, it seems fine now?

[macta]

Ok - I think I found the sequence in the history - it looks like

a98506fc813ee258af1725fc052bf580cef1c3ec is the merge that I had to do in git and ce6afeb08d3adc6615a01bedd0aead831d84b149 is the subsequent push?

In Pharo, I think 533767dd28ac1f6872f0525e3ef23948722f28e2 is the commit that it managed to do before trying the above merge?

Prior to that in intellij - I did c4f9042c1e177d852aca44625e50368ad1b5beeb to apply the generated files, then 6cd734523f2e03ae2a462f11e70f414f083fcda4 to fix a config file and then 9a07c2a123fea4300ae65275885db5126b11e962 in github to merge it onto master (it was after this that I did some testing and discovered a missing path and did that 533767dd28ac1f6872f0525e3ef23948722f28e2 commit)

I've attached an image from intelliJ that I think shows it, I've highlighted the point where I think I commited in Pharo and then had problems.

[macta]

I just hit the problem again (admittedly in the same image, which seemed to have recovered after I did my command line git). I think I need a new image to be sure - as its complaining about the same file ref: File @ /Users/macta/Dev/Smalltalk/Pharo/Pharo 6.1 - 64bit (tech preview)-ExercismDev/pharo-local/iceberg/exercism/pharo/exercises/reverse-string/.meta/hints.md

And this change (on a different branch) is purely a comment change that doesn't touch that file.