2014-09-09 3 views
0

Я хочу контролировать свою среду Subversion (Sliksvn 1.8.10) с помощью небольшой Java-программы на 64-битной машине Windows 7. Мне нужно использовать JavaHL (1.8.x), а не SVNKIt. Я реализовал функцию проверки хранилища, добавления файлов в рабочую копию и фиксации файлов в репозитории. В настоящее время проверка и функция добавления прекрасны. Проблема в том, что функция commit не работает правильно.JavaHL.Unable для совершения с моим java-приложением

public void commit() 
{ 

Set<String> paths = new HashSet<String>(); 
paths.add("C:\\Users\\XXX\\Documents\\SVNTEST\\Test3"); 
Depth dep = Depth.infinity; 
); 


CommitMessageCallback handler = new CommitMessageCallback() 
{ 
@Override 
public String getLogMessage(Set<CommitItem> arg0) { 
    // TODO Auto-generated method stub 
    System.out.println(arg0.size()); 
    return null; 
} 
}; 

CommitCallback callback = new CommitCallback() 
{ 

@Override 
public void commitInfo(CommitInfo arg0) { 
    // TODO Auto-generated method stub 
    System.out.println(arg0.getAuthor()); 

} 
}; 
try 
{ 

    client.commit(paths, dep, true, false, null, null, handler, callback); 

} 
catch(ClientException e) 
{ 
    // TODO Auto-generated catch block 
    e.printStackTrace(); 
} 

} 

Когда я обработать функцию фиксации, то я получить от CommitMessageCallback функционировать количество операций по фиксации предметов. Это работает. Моя проблема в том, что не получают CommitInfo из функции CommitCallback. Я думаю, что, возможно, процесс распадается в среде subversion, и моя функция не дает результата. После этого процесса элементы фиксации все еще находятся в статусе svn «Пункт назначается для добавления».

Я работаю над этой проблемой, так как несколько дней с другой версией JavaHL.jar api, но это не удалось. Большая проблема также в том, что я не получаю сообщение об ошибке, и я не знаю, что не так в коде.

Есть ли у кого-нибудь идея, что не так в моей функции фиксации? Возможно, файл libsvnjavahl-1.dll несовместим с некоторыми JavaHL Api's?

Большое спасибо

С наилучшими пожеланиями Саймон

ответ

0

Хорошо, я решил эту проблему сейчас. Легким решением было использование org.tigris.subversion вместо классов библиотеки org.apache.subversion. Но вопрос в том, почему существуют две разные версии из библиотеки JavaHL?

 Смежные вопросы

  • Нет связанных вопросов^_^