Jörg Schaible wrote:
Ovidiu Feodorov wrote:
Jörg Schaible wrote:
So, do you say that Cygwin's svn has a problem if you call it directly on
command line with an absolute path like
svn info /cygpath/c/path/to/managed/source
I can hardly believe this (cannot test it anymore, Windows free zone).
The error above indicates for me that you actually called something like
svn info /cygpath
I don't call svn directly, Maven does.
I know, but how should Maven work, if it does not work on your commandline?
That's exaclty what I wanna know. If your command line works, then you can
fix Maven. If not, then there's nothing to fix. ;-)
Command line fails when I use absolute paths.
Command line works when I use relative paths. If I were to use command
line with --target (which Maven does), I'd probably use relative paths,
it's more natural. Yes, I know, there's , so here's my proposal:
1. Expose a configuration option in SCM/SVN that will allow the user to
choose whether Maven creates --target file using absolute or relative paths.
2. By default, the configuration option is not explicitly declared, and
it defaults to "true" (use absolute paths), so nothing changes for the
majority of the users.
3. For cases like mine, I'd configure my environment to "false"
3.1 If I happen to stumble over long Windows paths with my "false" on,
then I am out of luck. I'll see what I do when I get there.
4. I document properly the option, so the users know they have this choice.
I don't claim to be the best solution, but it's a solution that works
for me, and won't impact anyone else if their configurations work for
them, and they don't change them. Basically, we're giving users options.
If they are well documented and appropriately provided with default
values, I don't see the harm.
The thing is, that I can normally call svn from everywhere as long as the
target path is managed by svn:
/tmp $ svn info ~/src/Maven/plugins/maven-help-plugin/
works for me although neither /tmp nor my home directory is obviously a svn
working copy. However, the bug you see in Cygwin is a bit strange, because
it means your svn looks also at the first path element ?!?
Yeah, I have no idea, I am not that ambitious to start looking into svn
source code :).
[snip]
This is the result of running svn from command line, with the same
target files:
$ svn ci -m "test" --targets
/cygdrive/c/Users/ovidiu/AppData/Local/Temp/maven-scm-45206-targets
svn: '/cygdrive' is not a working copy
svn: Can't open file '/cygdrive/.svn/entries': No such file or director
What's the content
of /cygdrive/c/Users/ovidiu/AppData/Local/Temp/maven-scm-45206-targets ?
I've pasted it in the previous e-mail. I am doing it again here:
---------------------------------------------------------------------------------------------------------
/cygdrive/c/work/playground/maven/release-plugin-experiments/pom.xml
/cygdrive/C/work/playground/maven/release-plugin-experiments/sub-module-one/pom.xml
---------------------------------------------------------------------------------------------------------
That file actually contains the real arguments ...
However, svn info works
$ svn info
/cygdrive/c/work/playground/maven/release-plugin-experiments/pom.xml
Path: /cygdrive/c/work/playground/maven/release-plugin-experiments/pom.xml
[snip]
Looks basically good.
Could be a bug in svn, I don't know.
$ svn --version
svn, version 1.5.4 (r33841)
compiled Oct 24 2008, 12:23:22
or one of the Cygwin port of svn. Depends on the file content above.
Yes, most likely. As I said, I am not that ambitious to start looking
into SVN code.
If you believe my Maven workaround exposed above it's acceptable, I'll
implement it and submit the patch and tests.
If not, I'll continue to use my locally patched version, and avoid to
upgrade as much as possible :). Not a good policy, that's true, but this
thing is somewhere at position 127 on my stack, I am using Maven as tool
to build something else, and my primary loyalty in terms of time and
priorities, is to that "something else" :).
Anyway, I appreciate you replying, thank you for that.
Cheers,
Ovidiu
