Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
Original issue reported on code.google.com by
martin.s...@gmail.com
on 23 Sep 2008 at 10:29