Home » Eclipse Projects » Subversive » binary libary
|
| Re: binary libary [message #3803 is a reply to message #2597] |
Tue, 01 August 2006 15:19   |
 Igor Vinnykov
Messages: 61
Registered: July 2009 |
Member |
|
|
Hello John,
Thank you for good points. Genarally all of them are already addressed in
Subversive. Let's go though them:
> 1) Use of command-line and eclipse based subversion interchangably. I'd
> like to use command-line commands sometimes. I wouldn't want to lose the
> option of switching to command line mode.
You can use Subversive together with other tools like command-line client,
TortoiseSVN, etc. It means that you can make some operations by one tool
then switch to another and continue without any complications. Till the
recent releases it was not so for all operations, but now we implemented
conflict editor, so you are able to handle temporary files, which are
created in case of conflict by standard SVN tools. Note that Subversive
avoid such files creation, but we included functionality to support then in
order to allow switch between Subversive and other tools.
> 2) Client-server interoperability. I don't want to be either of these
> situations:
> I can't upgrade my subversion server because I have eclipse users
> running an incompatible subversion client implementation.
> I can't use eclipse to interact with my repository because the
> repository has been upgraded to a newer version of subversion.
It's more or less the question about clients (or rather protocols)
compatibility. As far as I know SVN team aware about it, so described
situation shouldn't happen.
> 1) Eclipse can leverage the binary library that I have already installed
> on my system as part of my OS.
In case of pure Java library like JavaSVN this question doesn't actual. In
case of native JavaHL solution user should manage installation of
appropriate libraries by himself and it's a disadvanatge of this approach.
> 2) The svn proposal has an adapter plugin that will allow me to use a
> different client library. Can Subversive include this feature in their
> proposal?
We already implemented this functionality, because it's pretty important. In
the Subversive 1.0.1 we improved interface between project parts and defined
Eclipse extension points, which allows us to switch between different client
libraries. Currently we support JavaSVN and JavaHL, but it's easy to add new
library if it will appear in future (personally hope to see stable pure Java
library with EPL license). Current JavaHL-based solution is not tested
enough, but we plan to make it stable in the near future. It also doesn't
have some extended features of Subversive, because JavaHL doesn't contain
not standard features, which we added to JavaSVN. We are evaluating ways how
to handle them on top of JavaHL. Cooperation with SVN team on JavaHL
improvement is one of the possible options.
Best regards,
Igor Vinnykov
|
|
| | |
| Re: binary libary [message #3877 is a reply to message #3849] |
Fri, 04 August 2006 15:57 |
John J. Franey
Messages: 55
Registered: July 2009 |
Member |
|
|
Konstantin,
On my point, I do not joke. My point is that even at the most
superficial level, the JavaSVN client and the subversion client are
different in their behavior.
Konstantin Scheglov wrote:
> John J. Franey wrote:
>
>> Regardless of your assertion, I'm not 100% confidant that different
>> implementations are compatible. My organization is converting from
>> cvs to svn now and are in a learning ramp. One of our guys uses
>> IntelliJ which is based on JavaSVN. He found a way to run JavaSVN
>> from the command line. His experience using the JavaSVN in a command
>> line is different from the experience I have using the subversion
>> client command line.
>>
>> Here are some differences we have found after a couple of hours of
>> working with the two tools:
>>
>> 1) JavaSVN will do a commit without requiring a log message.
>> subversion insists on a log message; it won't even accept a blank line
>> entered in the editor.
>
> Huh? I did many times commits using this options: -m ""
> i.e. with empty log message. And I did not see any complains from SVN
> server.
Thanks. I didn't think to try specifying an empty string using '-m'.
Still, there is a (superficial) difference between JavaSVN and
subversion client.
>
>> 2) We're not sure JavaSVN is succesful in committing a single file, as
>> in: svn commit myFile.txt, because it doesn't output "Committed
>> revision 39." like the subversion client would.
>
> Are you sure that write was successful when you write some information
> in file and close it? This operation also does not output anything to
> console.
My only point is that JavaSVN and subversion client are different on
reporting back the status of a commit. I'm not making a useability
judgement on any tool. Sorry if I came off that way.
>
>> These differences don't make subversion and JavaSVN client
>> incompatible. However, they are enough to unsettle me. I'm sure I
>> would use the subversion client implementation in Eclipse. I'm sorry
>> I wouldn't be able to make use of features that depend on JavaSVN
>> extensions. I hope that I would be productive anyway.
>
> I hope that you just joke. At least your reasons look so.
>
I am not joking around the point that I would feel more comforable using
the client library that is maintained by the originators of subversion.
If you don't see my point of view, then I hope I'm giving you a good laugh.
Regards,
John
|
|
|
| Re: binary libary [message #4228 is a reply to message #3877] |
Tue, 08 August 2006 09:43 |
Eclipse User |
|
|
|
Originally posted by: michal.dobisek.polarion.com
"John J. Franey" <jjfraney@verizon.net> wrote
> Konstantin,
>
> On my point, I do not joke. My point is that even at the most superficial
> level, the JavaSVN client and the subversion client are different in their
> behavior.
I would say, that there is a little misunderstanding here. One thing is the
SVN protocol compatibility (which Igor Vinnykov refers to) - which is really
important during the Subversion development - you can in most cases use e.g.
old client with newer server and you will have no problem in most cases.
The other thing is the emulation of command line interface provided by
JavaSVN - differences in this have no impact on the client-server
compatibility. If I understood correctly, than all your points of difference
belonged to this category.
Cheers,
Michal
|
|
|
| Re: binary libary [message #4506 is a reply to message #4228] |
Tue, 08 August 2006 16:51 |
John J. Franey
Messages: 55
Registered: July 2009 |
Member |
|
|
Yes. I agree. There are two categories of compatibility: 1)
client-server and 2) client-client. I have concerns in both categories.
I apologize if I have mixed them up in above responses.
Michal Dobisek wrote:
> "John J. Franey" <jjfraney@verizon.net> wrote
>> Konstantin,
>>
>> On my point, I do not joke. My point is that even at the most superficial
>> level, the JavaSVN client and the subversion client are different in their
>> behavior.
>
> I would say, that there is a little misunderstanding here. One thing is the
> SVN protocol compatibility (which Igor Vinnykov refers to) - which is really
> important during the Subversion development - you can in most cases use e.g.
> old client with newer server and you will have no problem in most cases.
Yes. In most cases, no problem. However, there is no guarentee from
subversion team that a client from one release will work with a server
from another release. But this is ok for me, because when the server
upgrades, I upgrade my client because a client and server of a given
release are always avaialable from subversion team at the same time. Is
the same said for JavaSVN (subversive client)? In other words, will a
compatible JavaSVN client be avaiable at the same time as a subversion
server? Always...going forward?
>
> The other thing is the emulation of command line interface provided by
> JavaSVN - differences in this have no impact on the client-server
> compatibility. If I understood correctly, than all your points of difference
> belonged to this category.
>
Correct, all my points of difference belong to this category.
I have stronger feelings about this category. Mainly because the client
side of the conversation does more than just talk with the server. More
than just emulation of command line interface, there is some important
functionality that is implemented only on the client side (e.g. status,
diff, revert). These should behave the same in all implementations of
the client side. Also, the client side data will be accessed and
modified by client side implementations and clients should be compatible
in terms of these data formats and semantics. Finally, the clients can
be compatible in terms of configuration (although not expressly
necessary). This would allow my .subversion/config file and my
authentication cache be used by any client implementation.
> Cheers,
>
> Michal
>
>
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 02:01:16 GMT 2024
Powered by FUDForum. Page generated in 0.03857 seconds |
] 
Search
Help
Register
Login
Home
