Feature Request: Cygwin Path Support (Cross Platform Path Support)

[GoogleCodeExporter]

I know you stated that boar is designed to work with bash and windows cmd 
shells, so I'm not sure if you ever have occasion to use cygwin on windows. It 
would be nice if boar would do something intelligent when it sees a cygwin 
style path in terms of converting it to a compatible path so regardless of what 
style of path (*nix, windows, or cygwin) boar behaves correctly cross platform. 
Cygwin paths looks like "/cygdrive/drive_letter/path/to/file".

When making a directory a working directory I know the path value is stored in 
the info file; it is these that should be correctly interpreted if one 
shell/platform is used to make a directory a working directory and a different 
shell is used to make a check in from that directory.

Original issue reported on code.google.com by cryptob...@gmail.com on 15 Jan 2012 at 7:21

[GoogleCodeExporter]

I have used cygwin, but not much. What is your scenario exactly? Cygwin paths 
should look like normal unix paths, and boar certainly handles those.

Original comment by ekb...@gmail.com on 29 Feb 2012 at 12:55

[GoogleCodeExporter]

Specifically, I was referring to being able to navigate into a working 
directory created in one environment using a different environment and then run 
ci/co/status/etc and have it work.

The "repo_path" value stored in the info file in the .boar folder is where the 
hiccup is occuring. If I run boar in cygwin and then on the same computer try 
running boar from windows cmd prompt I get:

ERROR: The path /cygdrive/s/repos/boar_repo does not exist or does not contain 
a valid repository.

I am proposing boar *first* try to translate the path to something cmd will 
process (since boar nor cmd understand what to do with the /cygdrive/ 
mountpoint).

But yes, in a nutshell I'm referring to boar making a best (cross 
platform/shell) effort to find the boar repo from the info stored in 
"repo_path" of the .boar/info file before throwing up an error message.

I didn't know if this would come into play anywhere else but as far as I can 
see having dug thru boar a little bit more now, working directories are the 
only place where fully qualified/nonrelative paths seem to crop up (which 
introduces the peculiarities of the different mountpoint/drive letter 
specifications of the different platforms.

Original comment by cryptob...@gmail.com on 29 Feb 2012 at 5:06

[GoogleCodeExporter]

Ah, now I finally understand this issue. I see your problem. However, I don't 
think it is feasible to make boar understand and handle this situation. Also, 
this problem will go away as soon as there is a stable boar network server, 
because then the repo will be referred to by network name instead.

A workaround could be to enter the repo path as "/my_repo" and create a 
symbolic link from that to your real repo in both your main windows drive and 
your cygwin root. Not the most beautiful solution, but I think it should work...

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

• Changed state: WontFix

[GoogleCodeExporter]

REPO_PATH="/my_repo" works fine for cygwin since "/" points to the cygwin root 
just like in any unix like system, but dos/cmd treats "/" as a relative path so 
it wouldn't point anywhere consistent would it?

From within does have REPO_PATH="/my_repo" would mean cmd tries to find a 
"my_repo" folder in the current directory (or am I misunderstanding your 
suggestion?).

Original comment by cryptob...@gmail.com on 1 Mar 2012 at 8:09

[GoogleCodeExporter]

From within does have = From within windows*

Original comment by cryptob...@gmail.com on 1 Mar 2012 at 8:11

[GoogleCodeExporter]

Nope, forward slashes should work mostly the same way in windows. However, a 
path starting with slash will refer to the root of the current drive. 

So that is an important difference, "/myfile.txt" will refer to c:\myfile.txt 
if your shell is using c: and d:\myfile.txt if your shell is using d:. That 
could complicate the soft link workaround described above.

Any reason why you can't stay with cygwin? (I'd think it's a nicer environment 
than the windows command prompt anyway...)

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

[GoogleCodeExporter]

Yes the windows command prompt is pretty horrid, so I usually do stick with 
cygwin. When that's not an option I tend to use powershell over the cmd shell. 
That being said, it's not a big issue, I only created the issue because it 
might have been something that you were unaware of, and after going thru the 
trouble of creating a bunch of working dirs (and particularly in light of the 
fact that by design the workflow of boar seems to strongly encourage the use of 
ci after the initial import) being able to use ci on a working directory as 
long as the REPO_PATH variable is correctly set should be possible from any 
supported shell.

Hard coding the repo path in the .boar/info file in a shell specific way seemed 
to me to unnecessarily break workdirs.

I was thinking there were a few possibilities:

* boar could parse and convert the repo_path value it reads in from the info 
file into a "neutral" format and pass the demunged path to boar/python so it 
can find the repo.

* or boar could try to read the path in from the info file, if the shell 
doesn't accept the path as valid, then boar could check to see if there is a 
value indicated in the REPO_PATH environment variable and try to use that

I don't know what kind of checking boar is doing to make sure the repo path 
indicated in the .boar/info file is in fact the *correct* repo to be importing 
to in cases where someone might have multiple different boar repos. Say someone 
has a memory card they have setup as a workdir, if they plug it in to a 
different machine with a totally unrelated repo that is located at the same 
path (say c:\repos\boar_repo), does boar necessarily catch that?

Ultimately, the issue just came down to referring to resources (including the 
boar repo) in a uniform way for tools that are ostensibly cross platform. 
Otherwise, the user experience of trying to use something cross platform hits 
these annoying roadblocks (like having boar barf when it tries to use the 
repo_path from a workdir).

Does boar handle the case when trying to run ci on a "portable" workdir (ie 
thumbdrive or memory card) on windows and *nix?

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