Publishing is done to wrong repostory path.

[GoogleCodeExporter]

ivy-settings.xml:
-----------------
<svn name="myresolv" repositoryRoot="svn://host:3790/A/B/C/"
     userName="${svn.user}" userPassword="${svn.passwd}"
     checkmodified="true" binaryDiff="false" checksums="">
 <ivy pattern="D/[module]/[revision]/ivy.xml" />
 <artifact pattern="D/[module]/[revision]/[artifact].[ext]" />
</svn>

in build.xml:
-------------
<ivy:publish pubrevision="${ivy.new.revision}"
             revision="${ivy.new.revision}" 
             artifactspattern="${build.assemblies}/[artifact].[ext]"
             resolver="myresolv" 
             organisation="someorg"
             module="${ant.project.name}"
             srcivypattern="${basedir}/ivy.xml" update="true" 
             replacedynamicrev="false" status="release"/>

- What is the expected output? What do you see instead?

I expect the artifacts to be published in
"svn://host:3790/A/B/C/D/[module]/[revision]/"
instead they are published in
"svn://host:3790/A/[module]/[revision]/"

- What version of the product are you using? On what operating system?

I am using Ant 1.7.0, Ivy 2.0.0-RC1 and IvySvn 2.0.0-b3.

Thanks,
- Martin

Original issue reported on code.google.com by martin.s...@gmail.com on 23 Sep 2008 at 10:29

[GoogleCodeExporter]

What happens if you set binaryDiff="true" instead of false?

If this still happens please run ant with the "-d" flag and capture the output 
into a
text file and attach it to this issue (ideally one file with the output when 
binaryDiff=true and another with it set to false).

Original comment by massdosage on 29 Sep 2008 at 2:18

[GoogleCodeExporter]

I think there is one small confusion about repositoryRoot.

Repository root from what i have seen is the 
SVN repository root. So even if you set
repositoryRoot variable to "svn://host:3790/A/B/C/" and your svn repository 
root( use
svn info)  is svn://host:3790/A/ the publish will publish to
svn://host:3790/A/<SOMEPATH> and not to "svn://host:3790/A/B/C/"/<SOMEPATH>

Original comment by daniel.b...@gmail.com on 30 Sep 2008 at 4:34

[GoogleCodeExporter]

Yes, the repositoryRoot should indeed be set to your SVN repository root. Does
setting this as so fix your problem? Please let me know if that is the case so 
I can
close this issue. I will take a look at the documentation for this attribute 
and see
if I can make it clearer.

Original comment by massdosage on 1 Oct 2008 at 9:23

[GoogleCodeExporter]

The Ivy repository is _not_ located at the SVN root that is why I use the long 
path.
It works when resolving but not when publishing.
I'll try to do it the way you describe, but I still believe that the other way 
should
work just as well.

Original comment by martin.s...@gmail.com on 3 Oct 2008 at 10:22

[GoogleCodeExporter]

It seems that everything after the port number in the "repositoryRoot" is 
ignored
when publishing. If that is the intended behavior then I think the naming of the
attribute should be changed.

Original comment by martin.s...@gmail.com on 3 Oct 2008 at 10:42

[GoogleCodeExporter]

The repositoryRoot attribute must be set to whatever the root of your 
*Subversion*
repository is, not the path to a folder under this where you store your Ivy 
files.
For example, our Subversion repository root (as setup when we installed the
Subversion server) is

svn+ssh://somehost.last.fm/svn

We store our ivy files at paths like:

svn+ssh://somehost.last.fm/svn/java/repository/organisation/module/revision/some
file.jar

The IvySvn setup is then

repositoryRoot = svn+ssh://somehost.last.fm/svn
pattern = java/repository/[organisation]/[module]/[revision]/[artifact].[ext]

If you try set the repositoryRoot to something that is not the actual Subversion
repository root as configured in Subversion there will be unpredictable 
behaviour
(like ignoring the additional folders etc.) So in this case when publishing the
folder "svn" is taken from the repository root, and the rest from the pattern. 
Some
setups have their Subversion repository roots at a level of more than one folder
(e.g. svn/somepath/root) and in these cases the repositoryRoot is required 
otherwise
IvySvn doesn't know what path to base its requests relative to.

So, in summary, the repositoryRoot must be set to your Subversion repository 
root
only and any other paths below this must go into the pattern(s). In the 
documentation
I thought I made this clear by describing repositoryRoot as follows:

"SVN repository root location (including protocol, host and Subversion root 
path)."

if you feel this isn't clear enough let me know what you think it should say 
and I
will update it.

Original comment by massdosage on 3 Oct 2008 at 10:58

[GoogleCodeExporter]

Just to clarify a bit further, an Apache/mod_dav_svn setup can have several
repositories, all located in one common subversion base URL, like so

http://dom.com/svn/a-repository
http://dom.com/svn/b-repository
http://dom.com/svn/c-repository

Each URL above is a separate repository URL allthough they share the same SVN
installation. Morever the SVN installation can be put in an arbitrary path like

http://dom.com/some/arbitrary/path

Perhaps it is evident to all parties involved in which case I apologize!

Original comment by christof...@gmail.com on 9 Oct 2008 at 2:15

[GoogleCodeExporter]

I can confirm this defect: publishing always done against the repository root. 
The
ivy and artifact patterns are ignored completely.

Original comment by christof...@gmail.com on 9 Oct 2008 at 2:53

[GoogleCodeExporter]

I'm still not entirely sure what the issue is here. IvySvn 2.0 requires you to 
set
the Subversion repository root in the "repositoryRoot" attribute, and all paths 
in
the  patterns *must* be relative to this. If you try put other paths in your 
patterns
it's not going to work.

Can someone please give a detailed example of what they are trying to do - with 
ivy
settings, patterns, what the subversion repository path is etc.

Original comment by massdosage on 9 Oct 2008 at 2:58

[GoogleCodeExporter]

Well, it is simple, really...

If I have an ivy and artefact pattern similar to

  <svn name="subversion" 
    repositoryURL="${svn.url}/Binaries"
    userName="${svn.username}" 
    userPassword="${svn.password}">

    <ivy pattern="[organisation]/[module]/[revision]/ivy.xml"/>
    <artifact pattern="[organisation]/[module]/[revision]/[artifact].[ext]"/>

  </svn>

... and ${svn.url} is "http://dom.com/svn" all published artifacts end up in

  http://dom.com/svn/Binaries/1.3.0

... instead of 

  http://dom.com/svn/Binaries/org/module/1.3.0

The same problem applies to the binary diff strategy where the revision number 
is
replaced by "LATEST".

Original comment by christof...@gmail.com on 9 Oct 2008 at 4:24

[GoogleCodeExporter]

OK, but what is that path to the *Subversion* repository root? i.e. the value 
set as
the root when you installed and setup Subversion, without any notion of Ivy.  
Is it

http://dom.com/svn/

or

http://dom.com/svn/Binaries

If the former, then repositoryRoot (not sure how yours would work using 
repositoryURL
from your example?) should be set to 

http://dom.com/svn/

and the patterns should be 

<ivy pattern="Binaries/[organisation]/[module]/[revision]/ivy.xml"/>
<artifact 
pattern="Binaries/[organisation]/[module]/[revision]/[artifact].[ext]"/>

Original comment by massdosage on 9 Oct 2008 at 4:43

[GoogleCodeExporter]

It is the former,i.e. 

  http://dom.com/svn/Binaries

This is the repository root. The path 

  http://dom.com/svn

... is not to a *repository*, it really is to the the URI space handled by the
mod_dav_svn module which supports multiple repositories. For more information on
this, please consult

http://svnbook.red-bean.com/en/1.5/svn.serverconfig.httpd.html#svn.serverconfig.
httpd.basic

There you will find an example

  <Location /svn>
    DAV svn

    # any "/svn/foo" URL will map to a repository /var/svn/foo
    SVNParentPath /var/svn
  </Location>

The SVNParentPath points to a directory in the file system which contains an
arbitrary number of different repositories. 

Original comment by christof...@gmail.com on 9 Oct 2008 at 5:58

[GoogleCodeExporter]

OK, well, if you can send me how you have configured svn, what the root is set 
to
there, the path on the filesystem, and the webdav setup and I will try 
replicate it
here using a local test webdav installation and see if I can reproduce it. I'm 
afraid
the SVNKit API is completely horrible the way it works with paths so there are 
quite
a few issues with it that I haven't been able to resolve in more complicated 
setups
like this.

Original comment by massdosage on 9 Oct 2008 at 6:04

[GoogleCodeExporter]

Well, SVN runs on a Windows host and we use the VisualSVN distribution (which 
uses
Apache and mod_dav_svn). Not my preferred way of setting up SVN, but this 
company is
a Windows only shop.

Anyhow, the relevant portion of Apache configuration is 

<Location /svn/>
  DAV svn

  SVNListParentPath on
  SVNParentPath "D:/Repositories/"
  SVNIndexXSLT "/svnindex.xsl"
  SVNPathAuthz on

  AuthName "Subversion Repositories"
  AuthType Basic
  AuthBasicProvider file
  AuthUserFile "D:/Repositories//htpasswd"
  AuthzSVNAccessFile "D:/Repositories//authz"

  require valid-user
</Location>

For testing purposes and reproduction of the issue I would say you only need
something like this:

<Location /svn/>
  DAV svn

  SVNListParentPath on
  SVNParentPath "D:/Repositories/"
</Location>

As for the SVN repositories we use

D:/Repositories/Binaries
D:/Repositories/Tools

... and so on. Binaries is for the artifacts published with Ivy.

You will find the (edited) ivy.settings file attached.

Original comment by christof...@gmail.com on 9 Oct 2008 at 6:44

Attachments:

• ivysettings.xml

[GoogleCodeExporter]

Issue 8 will be the "lead" issue for this as others are most likely duplicates. 
All
further comments, watching etc. should be done here:

http://code.google.com/p/ivysvn/issues/detail?id=8

Original comment by massdosage on 27 Oct 2008 at 6:16

• Changed state: Accepted

[GoogleCodeExporter]

This should be fixed in IvySvn 2.0.0-rc1, if this is not the case please let me 
know.

Original comment by massdosage on 6 Nov 2008 at 7:22

• Changed state: Fixed