svn OPTIONS error can not publish if root is private

3 views
Skip to first unread message

luxspes

unread,
Mar 30, 2009, 10:42:08 AM3/30/09
to ivysvn
Hi

First, let me say you that is think ivysvn is a great idea!

Now, back to my issue:

Our repository is configured with permission using the Path-Based
authorization, the problem is, that since our svn is for internal
projects, and some of them are to be hidden even from people from
inside the organization, our configuration hides the "root" directory.

While this configuration is easy to get, it seems it is not very
common, because we keep getting "Can not read svn/OPTIONS" exceptions
when configuring our projects with subeclipse or subversive plugins of
Eclipse, but, it does not seem to be a major problem, because after
presenting us with this "error" Eclipse always ask us "Do you want to
continue anyway", we answer yes, and everything works perfectly fine
after that.

But ivysvn seems to be missing this ability to ignore the "Can not
read svn/OPTIONS" and allow us to continue... is this for a particular
reason? or could you add a configuration option to make it possible to
ski this svn/OPTIONS requirement?

luxspes

unread,
Mar 30, 2009, 12:26:55 PM3/30/09
to ivysvn
I have created an issue ( http://code.google.com/p/ivysvn/issues/detail?id=18
) with the full stack trace, I believe that the problem is in the
class
fm.last.ivy.plugins.svnresolver.SvnPublishTransaction at the method

public void commit() throws SVNException, IOException {
// reset the repository to its root and tell it to connect if
necessary
SVNURL root = commitRepository.getRepositoryRoot(true);
commitRepository.setLocation(root, false);
commitEditor = commitRepository.getCommitEditor(commitMessage,
null);
commitStarted = true;
commitEditor.openRoot(-1);
int putFileCount = commitTree(publishTree);
if (putFileCount == 0) {
commitEditor.abortEdit();
Message.info("Nothing to commit");
} else {
Map<String, String> foldersToCopy = prepareBinaryDiff
(publishTree); // prepare binary diff in existing
// transaction
commitEditor.closeDir(); // close root
SVNCommitInfo info = commitEditor.closeEdit();
Message.info("Commit finished " + info);
copyDiff(foldersToCopy);
}
}

I have not experience using the the SVNKit API, but think that the
problem is that you are going back to the "real" root directory '/
svn/' (SVNURL root = commitRepository.getRepositoryRoot(true);
commitRepository.setLocation(root, false);) instead of using the
value I provided in the ivysettings file: repositoryRoot="http://
10.10.1.26/svn/ivy/".

http://10.10.1.26/svn is the root, but that root is forbidden because
everyone is not allowed to see a list of all the projects in our
subversion server. I know this configuration works because we have
many Eclipse projects and we connect using TortoiseSVN, and Eclipse
subclipse and subversive plugins and everything works fine (subclipse
and subversive only complain about the restricted ROOT the first time
a project is "shared" but it is just a warning, not an error)

How can I reach the value I wrote in repositoryRoot at ivysettings
and use that as a root here?


luxspes

unread,
Mar 30, 2009, 4:51:41 PM3/30/09
to ivysvn
I created an (insufficient) workaround the problem in
SvnPublishTransaction.commit by writing this function:

private SVNURL getSubRoot(SVNURL source) throws SVNException{
SVNURL root = commitRepository.getRepositoryRoot(true);
SVNURL tmpSource = SVNURL.parseURIEncoded(source.toString()) ;
Message.info("tmpSource:"+tmpSource);
while(!tmpSource.removePathTail().toString().equals(root.toString()))
{
tmpSource=tmpSource.removePathTail();
Message.info("tmpSource:"+tmpSource);
}
return tmpSource;
}

to get the proyect "sub root" and use it instead of the repository
root... and it made SvnPublishTransaction.commit work, the problem is
that "getRepositoryRoot(true); " a lot of other places, specially
inside fm.last.ivy.plugins.svnresolver.SvnDao for many the methods
(like for example folderExists) and they all make ivysvn fail on my
repository configuration.

I think ivysvn does not need to all those getRepositoryRoot(true); it
should be able to work starting from a "subroot" folder, but I now no
longer think I will be able to fix this myself, I will try
thought...but I am starting to think that the answer is to find all
getRepositoryRoot(true) calls and replace them with a configuration
option read from ivysettings... sadly I am not experienced in writing
Ant tasks....

Any hints?

Thanks,
Regards,

luxspes

unread,
Mar 30, 2009, 9:15:53 PM3/30/09
to ivysvn
Hi!
Well, I wrote a patch, and submitted it to the related issue (
http://code.google.com/p/ivysvn/issues/detail?id=18 )
You can find more info on the patch written as comments for the issue.
Please review it and tell me what do you think.
Regards,

luxspes

unread,
Mar 31, 2009, 12:44:07 PM3/31/09
to ivysvn
Wrote another patch (and uploaded it to the issue in the tracker),
because while the previous patch fixed resource uploading, it broke
resource retrieving, but with this new patch everything seems to be
working fine.

Adrian Woodhead

unread,
Mar 31, 2009, 12:55:42 PM3/31/09
to ivy...@googlegroups.com
Hey there,

Thanks for these contributions. I'm afraid at the moment I don't have
time to look over them, but hopefully in the next week or two I will
have a chance. I can imagine the issue you describe causing problems.
The reason we use the repository root is that SVNKit is very finicky
when it comes to navigating file paths and this was the simplest
solution as it was the only way we could guarantee a file path. What
makes it even more frustrating is that it behaves differently when the
protocol is svn+ssh or http (i.e. webdav), so I'm a little bit concerned
that the patch you have made will work over svn+ssh but not over http. I
have unit tests which should quickly show whether this is the case or
not and I will let you know.

Regards,

Adrian

luxspes

unread,
Mar 31, 2009, 1:47:36 PM3/31/09
to ivysvn
Hi!

Thanks for answering, ivysvn is great!.

Well, do not be concerned of my patch failing over http, it seems to
be working fine ;-) (I only use http, no svn+ssh here) of course, it
could fail the other way (svn+ssh) around :-P.

Regards,
Reply all
Reply to author
Forward
0 new messages