Repository (Hg) Working Directory

[kkurasz]

Hello,

I just started evaluating Review Assistant and believe I have run into a fundamental snag with respect to the way we organize our code at my office. Distributed Version Control Systems such as mercurial are generally not tied to static file system locations. Is there any way I can configure Review Assistant to know about the central server repository URL rather than some local working directory?

Thanks,

Kris

[AlexeyN]

Hello,

Any user can overwrite the "Working directory" option in their client, i.e. everyone can specify here the path to the folder with their working directory.

[kkurasz]

Any user can overwrite the "Working directory" option in their client, i.e. everyone can specify here the path to the folder with their working directory.

At my office we don't have the requirement that, for a given repository R and developer D, R always resides in the same file system location on developer D's system. That is, when I checkout a codeset (set of repos) I'm free to root that codeset anywhere I want.

I'd be forced to update the working directory for every repository potentially every time I checkout a codeset. (Please assume we have good reasons for how we check out our code). We could probably write a post-checkout script that updates the local working directories for review assistant projects (repositories), however I'm curious to know if there are alternatives.

That users can override the "Working Directory" doesn't really address my original comment and question. DVCSs (lets assume Git or Mercurial for discussion purposes) allow repositories to be cloned to any file system location. Having a working directory in the "Review Assistant Options" -> "Projects" configuration seems counter-intuitive to my understanding of how DVCSs work.

If I'm misunderstanding, please elaborate. We're very interested in the IDE integrated code review process provided by Review Assistant and are interested in both integrating Review Assisant with our (potentially unique) office workflow, and potentially making Review Assistant a better product.

Sincerely,

--Kris

[AlexeyN]

At my office we don't have the requirement that, for a given repository R and developer D, R always resides in the same file system location on developer D's system. That is, when I checkout a codeset (set of repos) I'm free to root that codeset anywhere I want.

In that case each developer should enter his own path to the repository in Review Assistant Project settings.

I'd be forced to update the working directory for every repository potentially every time I checkout a codeset. (Please assume we have good reasons for how we check out our code). We could probably write a post-checkout script that updates the local working directories for review assistant projects (repositories), however I'm curious to know if there are alternatives.

Review Assistant does not require your repository to be up-to-date. You should only pull changes to your local repository and Review Assistant will be able to get review files from it.

[kkurasz]

I've done a poor job expressing the reasons for why the working directory approach is insufficient - however I don't want to get into the full details of our internal build system and justify why our repositories float around on the local file system.

I believe my question has been answered - no you cannot bind to the repository URL and that the working directory is your only option.

Thanks,

Kris