Better output for "ERROR: This import would replace some existing files" during import

[GoogleCodeExporter]

Boar terminated an import with "ERROR: This import would replace some existing 
files"

However I have no idea what those files might be nor anyway to troubleshoot 
this. A better/more helpful error message would be nice in terms of next steps 
as far as how to be able to fix this error and perhaps displaying which files 
might be replaces and allowing the user to do some sort of merge conflict 
resolution. "replace with backup" perhaps where the replaced files are stored 
in a special unresolved file conflicts folder?

Regardless, in the meantime, any advice on how to sort this out so I can pull 
the directory producing this error is much appreciated.

Original issue reported on code.google.com by cryptob...@gmail.com on 29 Feb 2012 at 10:43

[GoogleCodeExporter]

Hm... Yes, it is difficult to formulate concise yet useful error messages. 

I guess my idea how "import" should be used is to first import a directory tree 
once, then from then on use a boar work directory and "ci" to commit changes to 
the tree. If you already have a tree, "import" is not intended for repeatedly 
updating the repository with changes to the same directory. Although it allows 
for that situation as well, as long as there are no modified files, as you've 
noticed.

The message is intended to tell you that you are importing into an existing 
tree, which you probably didn't mean to do, hence no need for more details as I 
assume you'll take a look at your arguments and quickly realize your error... 
But I guess your problems shows that my assumptions are not perfect.

I'm not exactly sure what your sitation looks like, but in general, if you want 
to update a directory in the repository you should do this: 

1. Check out the directory ("boar co") 
2. Update it with the changes. 
3. Execute a commit ("boar ci")
4. Repeat from step 2 as required.

(Sorry if I'm explaining the obvious. I'm also writing for whoever else might 
be reading this)

But again, it sounds like you are using "import" in a slightly different way. 
Please explain further.

Original comment by ekb...@gmail.com on 29 Feb 2012 at 11:39

[GoogleCodeExporter]

Hello Mats. Thank you for your explanation, that does clear the purpose of the 
error message. In that case just from an end user perspective I would document 
the distinction about import/ci and make the error print out perhaps some hint 
about not using import to import over an existing tree.

The reason I got in the habit of using import instead of ci is the 
--ignore-errors switch. ci would fail when trying to import a "live directory" 
in which files may be locked for editing, or created/destroyed during the 
import (I am under the impression this is still the case, but I haven't tried 
it recently). I realize ideally a directory could be frozen in a consistent 
state during import, but since some of my working dirs are accessible to other 
users, I am perfectly happy with being able to ignoring errors and rerunning 
import to capture stray files at a later time.

The second reason I am rerunning import rather than using ci, is because the 
directory I'm trying to import wasn't turned into a working directory. I was 
importing an especially massive directory and once it was almost finished, my 
computer restarted. I checked the sessions folder and it contained all the 
relevant files and they all seemed well formed and complete including the 
session.md5

I wanted to be sure the import didn't miss anything and also to turn the 
directory in question into a work dir so that I *could* use ci. I thought 
running import on the directory with the relevant switches would accomplish 
this but instead I got the above error. Basically, I was trying to unnecessary 
io since boar had already created and hashed all the blobs and was processing 
them thru the tmp/queue directories and sucking them into the blobs folder.

Is there any way to gracefully resume an interrupted import in a situation like 
this? Or what is the best way to proceed in a way that will keep boar happy 
(and if possible salvage some/any of the work that has already been done)?

Original comment by cryptob...@gmail.com on 29 Feb 2012 at 3:30

[GoogleCodeExporter]

Regarding your last question, "Is there any way to gracefully resume an 
interrupted import in a situation like this?" the answer is simple: you don't 
need to. Boar makes sure that the import either succeeds completely or doesn't 
alter your repository at all ("atomicity"). If it is interrupted before it is 
done, but the new snapshot is available afterwards, then all is well. This is 
because Boar writes down what it is about to do, so that it can resume the next 
time it starts up. This happens behind the scenes.

That said, sudden power loss or system crashes might cause file system 
corruption outside the control of Boar. But if "verify" says it is ok, then all 
is well.

I'll create a new issue for adding --ignore-errors" to "ci" as well.

Original comment by ekb...@gmail.com on 29 Feb 2012 at 10:54

[GoogleCodeExporter]

The situation (I believe) that is still unaccounted for however is if a 
directory is imported and not turned into a working directory...

The import command doesn't force a directory to be turned into a working 
directory, so what happens if files are changed in a previously imported 
directory that hasn't been setup as a working directory?

If the intended workflow of boar is to use ci to import future changes to an 
already imported tree, then either import should force directories to become 
working directories, or there should be a way to allow directories to be 
reimported (even if a tree for that directory already exists) and turned into 
working directories after an initial import.

Otherwise, it seems that once you import a directory, if you didn't turn it 
into a working dir at the time and anything inside of that dir changes, you are 
at an impass.

Original comment by cryptob...@gmail.com on 1 Mar 2012 at 7:35

[GoogleCodeExporter]

Yes, it is unintuitive that import does not create a workdir by default. I'll 
probably change that in the next release.

It is quite possible to recover from this situation though. Check out the 
directory from the repository, move the contents from the old directory to the 
workdir, commit. 

Original comment by ekb...@gmail.com on 1 Mar 2012 at 9:31