_find_repo_path() default usage is worrying

[thread2]

As for versions, this relates for both currently "stable" version 1.4.3 and the latest development one as checked out today (actually on Friday April the 1st 2011).

As for the problem, I have accidentally found that on initialization ( class WikiStorage::init() ), hatta seems to ascend the directory tree, starting from the predefined position ./doc/.hg, in a search of some available Mercurial repository.

It happened so that I had one, fortunately designed for a newer version of Mercurial, so hatta just plainly refused to start (with a non-helpful message "fncache requirement not supported") -- what was something good, as I supposed hatta to be able to create its own repository in the 'doc' subfolder, according to what one could read in the wiki :  http://hatta-wiki.org/Install%20on%20Debian%20or%20Ubuntu%20Linux ,  http://hatta-wiki.org/Standalone%20server, and *not* wandering around my filesystem seeking for an innocent Mercurial repo to invade.

Suggestion:
either do something simple, such as:
=====

def _find_repo_path(self, path):

""" just check for the repository at a given path """

if os.path.isdir(os.path.join(path, ".hg")) :

return path

else :

return None

=====

Or, if necessary, make this "search and destroy" a non-default option.

Best,
/t2

[sheep]

This behaviour is actually consistent with the behaviour of any other Mercurial command. I can see how it can bite you though, as I've been bitten by it several times myself. On the other hand, I want Hatta to be able to store pages in a subdirectory of a repository, not necessarily at the top level (this way you can have several wikis in the same repo, or use the same repo both for code and documentation).

I can see several solutions:

• Leave the current behaviour, but don't create repositories automatically. This will keep Hatta consistent with all other Mercurial commands, and at the same time will avoid the surprise when you expected it to create a new repository but it used the old one. It will just always use an existing one. Error if there is no repository.
• Like above, but add an option for creating the repository if it doesn't exist.
• Don't automatically search for a repository, but instead add another option to specify a path for it. Default to the pages directory if it's not specified, error if there is no .hg in that directory. This is probably what you expect, but it feels like it cripples Hatta a little.
• Like above, but create the repository if it doesn't exist.
• Like above, but add an option to search for the repository, default to off.
• Like above, but make the search option a limit on how deep the search should go, default to 0.

What I don't like is actually the automatic creation of a repository -- somehow it feels wrong, but it lets you start using the wiki easily. I would choose the first option, but I'm afraid t wouldn't solve the problem you are describing, and adds an extra step needed. Third option also looks good, but it complicates minimal config even more.

[thread2]

Well, I propose then to declare this as a feature )

I mean, either the docs or the code should be changed imho. (At least the above-mentioned wiki pages seem to give false impression otherwise.)

As for consistency, I would disagree -- but it's true we have a subtle point here: first, Mercurial's "init" is explicit -- what is inconsistent with Hatta's behaviour, but looks convenient to me.
Second, apart from any relationship with Mercurial, unexpected side effects (when the documentation says "This will ... start a new Mercurial repository in the docs directory", I clearly expect it to be this way) are generally unwanted.

From the one hand, I see here something to be changed, as there is a thing that might be *not* expected by the user. From the other hand, if we change something, I think we have a moral obligation to be as backward compatible as possible. )

---

In that regard, I would discard both the second suggestion and the first, as my understanding of the first one is that by default it would silently serve some random hg repository from the filesystem, what may or may not be the thing the user wants )
Probably it would have been nice if we have had something like an explicit "hatta init" statement, but now this would be inconsistent with what hatta users expect it to do. And for me personally this closes the question: we want to /add/ consistency, not to break it.

Going to number three -- yes I like it ), and I think number four is even better -- both because it is similar to what happens now (finally we silently create a repo if we don't find one) and because it eliminates unnecessary annoying step (we still create the docs folder, after all).

Besides, we do not want insulting the users by assumption they _must_ understand something about Mercurial and why it's repository needs to be created : "here's my wiki folder -- I want a wiki here" -- I think it is nice and useful to provide this level of abstraction as well.

---

As for the versions five and six -- first let me speak about initialization.
In this case, I personally take this "let me guess" approach as redundant: in the case of a wiki the user is supposed to know where he or she wants it to be installed -- and in the case if it was completely forgotten, an explicit file search before making the decision might be the best option.

As for using hatta as a library -- I am a plain user at the moment, so I'm just speculating here. But I think that following the Mercurial convention on /commits/ is the right thing -- so I'd rather welcome such behaviour for actions like "hatta commit" if they exist; but even then -- so long as we have the config, and so long as it is available in the current context -- guessing about paths seems again to be redundant.
( Sorry if I do not express myself clear enough at this point -- at this paragraph I have bored even myself so it is difficult to stay clear ) )

---

But to summarize -- yes you're right that I would prefer number three, and I would even go further and decide on number four ; and no, I do not think it cripples the config (at least, it does not imho cripple it a lot) -- provided that by default the user does not have to know about this new option.

Best,
/t2

---

Gee, writing so many words on so few lines! They must really deserve that !