Bugzilla – Full Text Bug Listing
| Summary: | [Team] Support for subversion | ||
|---|---|---|---|
| Product: | [Technology] Subversive | Reporter: | Matthew Conway <matt> |
| Component: | Core | Assignee: | Alexander Gurov <a.gurov> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | a.gurov, A.Kuckartz, alex.blewitt, alex, analogue, andreas.hochsteger, andreas, antonin.pokorny, antonio, atrus1, bkonrath, boa, bogofilter+eclipse.org, bpasero, brockj, chen_shaopeng, chris, chris, chris_42, chuck.mccorvey, codex69, daniel, david.varnes, dev, digulla, dlr, donv, ed.burnette, fernacolo, florin, gloegl, gunnar, hans, hauser, i.vinnykov, igor, isobe, j3ns, jean-michel_lemieux, jeff, jimisola, joerg, justin, kariem, Konstantin.Scheglov, mauromol, mayweg, mguillemot, Michael.Valenta, michal.dobisek+eclbugzilla, mik.kersten, mkamp, mlists, mortench2004, nico.lichtmaier, ondrej.chylik, overholt, pali, pjs, pmuellr, preuss, ric.almeida, Sam.Mesh, scottr, sekundes, sflaniga, spamfaenger, stmoebius, tfmorris, thatnitind, todd.chambery, torsten.juergeleit, tromey, vmpn, wbeckwith, webmaster, wmitsuda |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Matthew Conway
We agree. But we would need a bit of help to get things started. First off, if someone would provide us with a reliable java binding to the subversion client library the we (the CVS team) would kick off the eclipse integration. We just don't have the time to write the binding and client ourselves. I've actually already logged a bug against subversion to add cancellation and progress to their client interface. It was fixed in release 18. This would of been a major obstacle in writting a robust client. If you are serious about wanting subversion, help out with the bindings. Doesn't an api already exists here: http://svnup.tigris.org/ Thanks for the pointer. The svnup project does have a java binding and I took a quick look at the source. It's in ok shape and would be an excellent starting point for writting an Eclipse client. The one thing that I did notice missing was callbacks in the API (e.g. progress and cancellation and log batons). This would have to be added before any useful client could be written. An alternate java client implementation can be found here: http://www.alternatecomputing.com/jsvn/index.php3 The alternate computing binding is a CLI (command-line client) based. Probably doesn't provide the flexibility we would need for rich integration into Eclipse. Basically there are two camps in terms of binding subversion to java. 1. use the CLI 2. use a JNI binding to the subversion client API. I prefer option 2. It provides more flexibility available in the API that isn't available in the CLI. Someone should start an Eclipse Subversion plugin project on tigris :) Looks like someone released a functional plugin for subversion: http://subclipse.sourceforge.net/ The problem with the JNI approach is twofold: o It requires a SVN-JNI client to be compiled for each platform o Changes in the SubVersion server can break the client using the JNI interface The subversion.tigris.org uses svn-up, which in turn is based on JNI, but (at present) only for the Windows platform. I have heard that it is possible to interrogate an SVN server directly using WebDAV, rather than requiring connections through JNI, which would solve both problems. Another integration option is accessing SVN using command line interface, in a way similar that Ant does with CVS. There is an open source project at http://supervision.tigris.org/ that uses CLI, and maybe some sources of it can be used. Please forget my previous comment. I didn't have read Jean-Michel comments about CLI. FYI, We don't plan on providing subversion support as part of the SDK. While eclipse.org is CVS based, the default scm provider in the SDK will be CVS. But as you probably know, there are a couple of groups already working on subversion plug-ins: http://subclipse.tigris.org/ http://svn4eclipse.tigris.org/ In Eclipse 3.0 we are making most of the code we used to build CVS as API. Other providers should be able to make their Team plug-ins as integrated as CVS. After talking to Michael Valenta at Eclipsecon I was going to request support for subversion but found this entry. The external plug-ins are a good start, but if subversion really supplants cvs it will be important to support it in the SDK. In fact this support could help drive conversion. Perhaps one of the subversion plug-in developers would like to contribute? We're not using subversion yet (heck, we just converted to cvs a couple years ago) so for me at least this is a future need not an immediate one. I think a subversion support in eclipse will be very fine. Currently, The Apache Software Fundation started moving some projects to subversion: https://svn.apache.org/repos/asf/ Also RedHat Fedora Core 2 will include subversion support too: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118724 Subversion is starting to be widely deployed. Eclipse.org is widely used for Java development I think it would be fine to support Subversion too. The SvnUp (http://svnup.tigris.org) Java binding is now the javahl binding in the subversion projects. It is not only available in Windows, but also on non Windows systems like linux or MaoOs X. Should anybody needs new feature or has problems for the eclipse support, please contact me mayweg@qint.de, because I am responceable for this bindings. subclipse now has bindings for osx, win32 and linux. if eclipse.org wants to do something really, really cool, write a pure java svn client implementation. perhaps based on the slide dav client? once this happens svn integration to eclipse will suck by 75% less (i see no need to support all the funky svn access methods, just http and https). subclipse currently runs into problems (hence low adoption) due to the many lib dependencies (apr, neon, berkeley, their dependencies etc etc). that being said, subclipse is usable from what i can tell. no large java projects have used it yet though (svn or subclipse to my knowledge). The core Subversion libraries used by the various aforementioned Subversion clients encapsulate some very complex logic which would be costly to duplicate in an alternate implementation. For simple browsing and auto-versioning with a Subversion repository over WebDAV, a Slide <http://jakarta.apache.org/slide/> based client would probably do the trick. Slide has solid WebDAV support, and claims basic support for DeltaV (the _V_ersioning portion of WebDAV). However, to make full use of the Subversion's capabilities, you really need a Subversion client built using SVN's own libraries. This becomes painfully obvious when considering SVN's multiple repository access methods: file system, its custom svn protocol (a la CVS pserver), or DAV. I'd like to see Eclipse bundle support for Subversion, and even use SVN to host its own source code. But all in good time. For now, I note that Eclipse already has platform-specific binaries. Including more platform-specific code is not such a burden, especially considering that the code is built around APR (the Apache Portable Runtime, a la NSPR of Mozilla project fame), originally created specifically for portability of a little program named Apache httpd. An implementation like what Subclipse uses might be a good compromise, where if the SVN core library bindings that it uses aren't available, it attempts to fall back to the commandline (which was designed with machine-parsable output in mind). Ack. I see no advantage in re-implementing the client side workspace management logic. Trust me, we do it for CVS in the current Eclipse client and it's a royal pain in the #$%. We always have to play catch-up with the server. What I would like to see is the Eclipse subversion community consider the subclipse plug-in as the Eclipse subversion story. We (I'm referring to the current Eclipse Team/CVS committers) may consider joining the community to evolve the plug-in and prove that it can scale and replace CVS. the java cvs client api was exactly what i had in mind actually... but apparently a java svn implementation is too horrible to comprehend ;) As a subclipse committer, i (and the rest of us i'm sure) more than welcome any help from the team/cvs eclipse people! fortunately, you'll find subclipse rather familiar, as it's basically a port of the current cvs team plugin. currently our biggest problem (imho) is getting the unix/osX native bits compiled statically, to ease the burden of having to build and install svn itself to use the plugin. #2 is getting subclipse up to snuff with the new synchronization api (and the old api for the 2.x stream). I grabbed the latest integration build last night and noticed new synch api's have been put in place. is it too soon to start building to the new team api? little of the new hotness was in m7.. The synchronization APIs in M8 are in a pretty stable form. Of course, until 3.0 ships, there will be some minor changes and improved javadoc.We've started writing ISV doc, but it isn't finished yet. You can preview in the plug-in developer section under programmer's guide > team support. Just as a heads-up, there are a couple of key elements that subclipse will have to provide in order to integrate well into Eclipse: 1. Figure out how to query (hopefully quickly) a variant tree from the repo. This is used for merging/synchronizing/comparing... It's basically the old "-n update -r <tag>" in CVS that we use to get the revision numbers for files in the repo. 2. Build a robust cache for maintaining sandbox resources states (e.g. the configuration of the resources in your sandbox). 3. Allow the cache to be re-entrant. 4. Figure out how to show moves when synchronizing/comparing/merging and how to write the movedelete hook to actually move the file in the repository. 5. Ensure that long running server operations are cancellable. We have a set of useful input/output streams that support fine grain cancellation that could be used, but the server and client APIs will have to support cancellation and progress as well. Good luck. We won't be able to help out much until 3.0 ships though. In the summer, we may be able to help out. where would be a good place to watch for the completion of the synch api docmentation? i'd love to get into implementing the new compare/sync apis for svn, but the docs in m8 aren't done baking, and the api is a bit complex to rely on javadoc alone. I'll post to the platform-team-dev@eclipse.org when the docs are in good shape. But this probably won't be before M10. Since M9 is our feature complete target we are concentrating more on finishing some of the features. Just a heads up that I'm working on the org.eclipse.team.examples.filesystem example to show how to use the new synchronize APIs. Also, by next week the docs will be done. I look forward to seeing a rockin' subversion plugin soon! *** Bug 69327 has been marked as a duplicate of this bug. *** There is also an exiting Java Subversion Client at http://jsvn.alternatecomputing.com/ - probably the svn access code from there could be used The Java Subversion Client invokes and parses the Subversion command line. Subclipse already has the ability to switch between the native libs and the command line. The command line option was added for those platforms where we don't supply a native package (IE not Win32, Linux, OSX). Using native libs is NOT a problem and is done in several other core Eclipse projects. A pure Java Subversion client is probably never going to happen, because it's too hard .. and it's not needed. My department of 75 developers is considering subversion. We'd really like to see it available in eclipse in the standard download. A lot of us feel like subversion's similarity to cvs and the fact that it fixes a lot of the biggest cvs design flaws are reasons why this tool is gaining huge momentum and I don't think we'd be surprised to see subversion overtake cvs as the defacto source control tool in the near future. There's a pure Java implementation of the Subversion client library available: http://tmate.org/svn/index.html They provide an Eclipse 3.0 plugin containing the client library too. The link in comment #26 redirects to http://tmatesoft.com. Try this link instead: http://tmate.org/svn/. The TMate SVN library is licensed under a "BSD-style" license. I have to say: This is the bug with the fourth higheste number of votes on the whole bugzilla. As far as I can tell, no one has actually LOOKED at this for 6 months. This is not cool at all. Will this ever get done? It also seems like the Assigned To is a routing account. Has this bug slipped through the cracks? (A somewhat frustrated Eclipse user) One of the cool things about Eclipse is that something doesn't have to be built-in to the base platform for it to be useful. CVS is part of the SDK download because that is the repository used on eclipse.org. But why CVS and not Subversion Arch, Bitkeeper... well it's really just a selfserving thing that the Eclipse team needed something to self-host. Until eclipse.org decides to support more repositories, there are no plans to add a subversion plug-in into the Eclipse SDK. The good news is that there are some good quality subversion plug-ins available. (In reply to comment #29) > One of the cool things about Eclipse is that something doesn't have to be > built-in to the base platform for it to be useful. CVS is part of the SDK > download because that is the repository used on eclipse.org. But why CVS and not > Subversion Arch, Bitkeeper... well it's really just a selfserving thing that the > Eclipse team needed something to self-host. <sarkasm>So until you gonna need a feature yourself you're not integrating it into Eclipse?</sarkasm> Sorry but I seriously think you should rethink this policy a bit. If the Quality of the plugins is so high, why don't you integrate it into the Eclipse default download? The real problem here is not that there is a way to somehow add Subversion support to Eclipse, this Bug is about the Problem that this should be supported from Eclipse by default. (In reply to comment #30) > <sarkasm>So until you gonna need a feature yourself > you're not integrating it into Eclipse?</sarkasm> > Sorry but I seriously think you should rethink this policy a bit. Isn't that all about Open Source? You need something ... you write it. > If the Quality of the plugins is so high, > why don't you integrate it into the Eclipse > default download? Because it's not an Eclipse.org plug-in. As soon as this plug-in will be part of the Eclipse platform drop Eclipse.org is in charge for supporting it. People expect to use the Eclipse newsgroups for support requests and the Eclipse Bugzilla for bug reports. > The real problem here is not that there is a way to > somehow add Subversion support to Eclipse, this > Bug is about the Problem that this should be supported > from Eclipse by default. I agree that it would be better if subversion would be included into the Eclipse platform drop. However, there is a clean and well definied way if you want a plug-in to become an Eclipse.org plug-in. If you really want this I suggest that you find some stakeholders and propose a new Technology sub-project. Once this project is approved you can go ahead and move the development of the subversion plug-in to Eclipse.org. However, I would also suggest expanding the project aganda a little bit. It should also include the creation of subversion repositories for interesting Eclipse.org projects to provide a clean migration path. It is a shame that eclipse does not support subversion (brings back some memories of companies sticking to "DOS" and refusing to port their software to "Windows"). Netbeans announced at JavaOne 2005 that they are going to support Subversion. Eclipse fundation should reconsider. +1 *** Bug 112748 has been marked as a duplicate of this bug. *** Subclipse is very good. I think if eclipse.org ever plan to support Subversion, it should consider starting with Subclipse implementation (and Subclipse commiters?). Of course, licensing questions must not be forgotten and may require more than simply copying the sources from a place to another. BUT... this is a dream, and until there, using Subclipse will be fine. We must always wait for Subclipse to support the latest Eclipse, and always download and upgrade Subclipse manually. But those tasks are worth of cost savings provided by Subversion and Subclipse (speaking of cost savings, maybe eclipse.org should consider using Subversion for self cost savings). There is cheaper, smaller thing, other than supporting Subversion, that eclipse.org could do to help community: resolve bug 74393. This bug is preventing Subclipse from supporting a nice "Compare To" > "Another Branch or Version" (wich reads "Another Directory/Revision" in Subclipse). Of course, Subclipse could implement the entire diff UI (I think), but that wouldn't look nice in an open source and object oriented environment. JavaSVN 1.0, an all-java implementation of the subversion protocol, just came out (http://tmate.org) but the free license changed to be be viral. TMate support says the version that was under a BSD license is still available: > You may check out version 0.9.2 and build it from sources using ant > program. The repository location for this version is > http://72.9.228.230/svn/jsvn/tags/0.9.2/ (In reply to comment #36) > JavaSVN 1.0, an all-java implementation of the subversion protocol, just came > out (http://tmate.org) but the free license changed to be be viral. TMate > support says the version that was under a BSD license is still available: It should be possible to create a fork. However, I don't think that it will ever become an official Eclipse.org project until it's relicensed under the EPL. The only solution I see: - Create a fork of JavaSVN at SourceForge - Keep the JavaSVN BSD license and ship it as a library plug-in - Prototype an Eclipse plug-in that uses the JavaSVN fork and shows how to reuse much of the CVS code - Propose a subproject below the Technology subproject, which goal should be the generalization of the CVS plugin to work with CVS and Subversion I volunteer to get the process started and do all the necessary work and communication with the Foundation. However, I don't have the time to be a full-time committer on such a project. But I'm willing to bring as much of my experience developing the ClearCase plugin an analyzing the CVS plugin as possible into that project. I think that such a project can be successful. However, we need support from the Subclipse as well as the Eclipse CVS community. I can also imaginge that such a project can switch to self hosting at some time, i.e. hosting on a Subversion server provided by the Eclipse Foundation. I can also imagine that such a project can become a part of the Eclipse Platform. So, what do the committers of Subclipse think? Is JavaSVN usable? Would this be the right approach? Would you join such an effort? What does the CVS team think? Hello All, My name is Alexander Kitaev and I'm developing JavaSVN library. Personally, I would like Eclipse to include Subclipse and JavaSVN. Forking of the library is, from my point of view, is the worst possible solution. Not only it duplicates the efforts, but also it will require additional efforts to replicate new features that eventually will be implemented in JavaSVN (like support for "file" protocol that is planned to be completed till the end of this year). I think there are several possible solutions regarding including JavaSVN into Eclipse, that will not require creating a fork: 1. I could provide a special version of JavaSVN that will be licensed under special, non-EPL compatible, license, that will allow library redistribution in any form along with Eclipse, but will limit library usage to Subclipse only. Actually, current license already allows this, but probably this could be explicitly mentioned and clarified in the license text. 2. Another option is to relicense JavaSVN library under EPL license under condition that JavaSVN will receive some kind of sponsorship from Eclipse foundation. Alexander Kitaev. I am a part time committer for Subclipse. From what I have seen the JavaSVN library is perfectly usable. In some cases it is actually better than the native libraries. I don't believe forking is the best solution. SVN changes quite quickly and neither the Subclipse team, nor the Team team would have enough resources to keep the client library up to date. Honestly, I don't know how Alexander does it. My name is Mark Phippard and I am one of the project owners for Subclipse, I just thought I would add my thoughts. In the long term, I would like to see Subclipse move to Eclipse.org. However, it really only makes sense to do so if the core Eclipse team developers have the time and desire to contribute. Otherwise, we would just be creating additional work that didn't have much benefit to the end user. Subclipse is fairly actively developed, as is Subversion, so we typically have releases every month. Moving to Eclipse.org would greatly slow that down, and now might not be the best time to do that. I do not completely understand why people feel Subversion support needs to come from Eclipse.org. Subclipse is actively developed and supported, and licensed under the CPL. It seems like the whole point of the Eclipse architecture is to support the development of robust 3rd party plugins. What message is it sending that every plugin needs to come from Eclipse.org? I would think that a product like Subclipse is a good validation of the Eclipse architecture and ecosystem. It would probably bring a bit more visibility to be part of Eclipse, but a Google for "Eclipse Subversion" or "Subversion Eclipse" bring Subclipse as the #1 hit so how hard can it be to find? My motivation for moving to Eclipse.org would be more committers. Ideally the existing Team committers would pitch in, and being part of Eclipse.org might bring some other new committers. I also think that in the long term we could benefit from some of the engineering practices of the Eclipse team. For example, currently the only part of our project with unit tests is the Subversion API layer. Nothing unit tests the Eclipse plugin layers. Subclipse includes a high-level Java API called svnClientAdapter. It provides an abstraction of the Subversion API and allows us at run time to use one of three different API's for accessing the repository: 1) JavaHL. The official Subversion Java language bindings. Thes use JNI to talk to the Subversion native libraries. 2) JavaSVN. A 100% pure Java library written by Alex at tmate.org. 3) CLI. The Subversion CLI. This one largely exists because it is easy to setup for the user. It is somewhat incomplete, but there were a lot of XML features added to Subversion 1.3 that should allow this to become more robust and complete. JavaSVN is excellent and Alex has been very responsive and helpful to us. Had it always existed I am not sure if the CLI adapter would exist. JavaHL has a bad reputation with some, but it is largely undeserved, at least today. Most of the problems with JavaHL have been building/obtaining it. We were also learning a lot about it over the years and for a long time lacked a knowledge base about how to get it working. I think these issues have been mostly resolved. a) JavaHL is pretty easy to build now when building Subversion. This was not always the case, but is today. b) There is a lot more Linux distribution support for including it in distributions. Debian packages and SUSE RPM's now exist. c) An easy to install OS X package has existed for a long time. d) Subclipse is able to provide it for Windows users as part of Subclipse. On Linux, you typically have to set LD_LIBRARY_PATH to include the path with the JavaHL library. This is a JVM issue and I have seen messages that some of the newer SWT feature also suffer from this problem. It is possible that with some of the knowledge of people at Eclipse.org that a version of JavaHL could be built and provided that would work with all versions of Linux. We currently choose JavaHL as the default adapter, but we automatically fallback to JavaSVN if JavaHL is not available. This has all greatly improved the initial Subclipse experience. I think Eclipse.org could get some benefits by providing a Subversion implementation: 1) CVS and Subversion have a lot in common so there could probably be a lot of refactoring work done to let the two plugins share code. In the process, this might create more building blocks for other team providers to use. 2) CVS and Subversion have enough differences that the Team API could be extended and improved by having a second implementation around. Let's face it, the current Team API is largely driven by what you can and cannot do with CVS. Extending the API to handle more of the things that Subversion can do would likely benefit a lot of the commerical SCM providers that have similar features. For example, Eclipse does not let a team provider capture a copy event. Also, the Synchronize API and model is not a great fit for all of the Subversion API's. Finally, as has been pointed out, Subversion supports meta- data (properties). It might be nice to possibly extend the Team or Platform API to support this concept. I have used plugins which invent their own system for storing meta-data. It would be cool if there were some API for this that maybe had a defauly filesystem implementation but that a tool like Subversion could provide another method to support. Anyway, I have more to say, but this is already too much. I think this really sits in the lap of the Eclipse Team committers. If this is something they are willing to actively work on, then we should make this happen. If they do not have the time, then I do not see the point in moving this under the Eclipse umbrella. Thanks Mark, thank you for your comments. It is my understanding that, in general, creating a new Eclipse project does not mean that existing Eclipse committers on other projects will become involved. This may happen in rare cases but usually new projects bring their own set of comitters with them. In this specific case, I can definitely say that the Team/CVS team does not have the manpower to consider supporting another repository client. Having said that, the final two points you made are valid. I am especially interested in point 2. If I were you, I would log an enhancement request describing why the current synchronization APIs are not a good fit for Subversion (i.e. we haven't heard much from anyone about the synchronization APIs up until this point). Also, we are currently in the process of defining APIs to support logical model interation with repositories (see bug 37723). We have an initial cut at model based merging available in M3 and are working out additonal API for M4 (such as using EFS (new in 3.2) for remote browsing, file history API, how to support renames during a model based merges, etc). Now would be a good time to get involved! (In reply to comment #40) > I do not completely understand why people feel Subversion support needs to come from Eclipse.org. I think I speak for many of the Eclipse users here, when clarifying this. What we all really want is that Eclipse ships with Subversion support out of the box. Whatever the best way is to develop the Plugin itself you and the developers surely know best. But it absolutely should become part of the standard Eclipse install. (Or perhaps a wrapper plugin that exposes the activation points which auto download the actuall plugin, as soon as you try to use it - though I still think that the real thing should come with eclipse from the get go.) (In reply to comment #42) > (Or perhaps a wrapper plugin that exposes the activation points which auto download the actuall > plugin, as soon as you try to use it Please don't go down this route as it doesn't play very nicely with Linux distributions' Eclipse packaging efforts. It seems to me (and note I'm not a subclipse/javasvn developer, just a user) that the best thing for users would be to make Subclipse an eclipse.org project. It meets just about all the requirements for an Eclipse project (vibrant user community, open source, etc.) so it's very likely to be approved. The current committers would simply become eclipse.org committers on this new project. The primary reason to go to the trouble to do this is so that the Eclipse Callisto release will include Subversion support. I think it's safe to say that any downloads released by eclipse.org will not include non-eclipse.org plug-ins. Does anybody disagree with that? I assert that Subversion support is strategically important to the Eclipse IDE, so it needs to be included in these bundles so that Eclipse will support SVN "out of the box". Simple as that. (In reply to comment #44) > It seems to me (and note I'm not a subclipse/javasvn developer, just a user) > that the best thing for users would be to make Subclipse an eclipse.org > project. It meets just about all the requirements for an Eclipse project > (vibrant user community, open source, etc.) so it's very likely to be approved. > The current committers would simply become eclipse.org committers on this new > project. The primary reason to go to the trouble to do this is so that the > Eclipse Callisto release will include Subversion support. > > I think it's safe to say that any downloads released by eclipse.org will not > include non-eclipse.org plug-ins. Does anybody disagree with that? I assert > that Subversion support is strategically important to the Eclipse IDE, so it > needs to be included in these bundles so that Eclipse will support SVN "out of > the box". Simple as that. Ed, there will be some issues: -- JavaSVN library used as default is not CPL and can't be used in commercial apps. I believe Alex can comment on this since he is in CC list. -- JavaHL is a native wrapper and there is an assumption that binaries are available on the platform (except win32, whose dll's are included with Subclipse) -- Subclipse is using Eclipse 3.0 API, due to needs of the Subclipse team (probably dependency to Rational RAD), so some important team features are not available (including commit/change sets). Another thing is that Subclipse team intentionally choose not to follow standard Eclipse team actions (argument is that these actions only used by CVS plugin, so not a rule) and more oriented to the way how cvn client and TortoiseSVN work (eg Switch... vs Replace with Another Branch or Version..., Pending Operations view, etc). Don't get me wrong, Subclipse team done a huge work, but as Michael pointed out now it is time for much tighter cooperation with team core team. I also would like to remind that there is need for unified team actions, such as commit, apply patch, create patch and few others. So, these actions could be called by plugins that support development process and integration with issue-tracking systems (eg Mylar). So, it is an opportunity for Team/CVS and Subclipse developers to cooperate, but it doesn't seem that either of them have interest in such API. I'm adding Mik Kersten to CC, so he can comment on this. Also see somehow related ussues 37705 and 116084. (In reply to comment #45) > -- Subclipse is using Eclipse 3.0 API, due to needs of the Subclipse team > (probably dependency to Rational RAD), so some important team features are not > available (including commit/change sets). It is true that Subclipse is trying to maintain compatability with 3.0, but this has nothing to do with the Team API. The only thing we are holding back are some SWT enhancements we could use and one change with the Console view. We are already exploiting the 3.1 features that we can. For example, when an SVN project is imported into a 3.1 workspace it is auto-shared with SVN. The commit/change set feature in CVS is nice, but it is not exposed as API to my knowledge. So it is not really fair to say that we do not support this feature. > Another thing is that Subclipse team intentionally choose not to follow > standard Eclipse team actions (argument is that these actions only used by CVS > plugin, so not a rule) and more oriented to the way how cvn client and > TortoiseSVN work (eg Switch... vs Replace with Another Branch or Version..., > Pending Operations view, etc). Is there such a thing as a standard Eclipse team action? It sounds to me like what you are trying to say is that we did not always use the same terminlogy as the CVS plugin. The CVS plugin is not the Team API, it is one implementation of it. We follow all of the conventions of the Team API, there are just certain places where we thought it made sense to use the Subversion terminology. Subversion has a command called "switch" that you use to switch your local copy from one branch to another. So we have a Team -> Switch option. Is that bad? We could add a Replace with -> Branch/Tag option as well. We have a lot of features the CVS plugin does not have, as they have features that we do not have. Given that we are a Subversion plugin, and they are a CVS plugin doesn't that only stand to reason? Is anyone entering enhancement requests to the CVS plugin for features that CVS does not provide such as atomic operations and meta-data versioning? I would hope not! > I also would like to remind that there is need for unified team actions, such > as commit, apply patch, create patch and few others. So, these actions could be > called by plugins that support development process and integration with > issue-tracking systems (eg Mylar). So, it is an opportunity for Team/CVS and > Subclipse developers to cooperate, but it doesn't seem that either of them have > interest in such API. I'm adding Mik Kersten to CC, so he can comment on this. > Also see somehow related ussues 37705 and 116084. Expanding the Team API would be great. I am sure there are a lot of commerical providers that would agree. Using SVN as a proving ground for this expansion would make a lot of sense as SVN addresses a lot of areas that CVS does not but which other commercial providers do as well. Expanding the Team API has to come from within Eclipse.org though. Subclipse would be happy to participate and support whatever new API is created. We have entered issues when there is something missing that is hindering us, such as a hook for the Copy event. If Eclipse.org wants to make some standard dialog and view API's, we would look at using them but it is not something we are going to ask for. Please God, let there e Subversion support equal or greater to the wonderful CVS support we now have. Oh yes, and let there be peace on earth. But I'l settle for the former. I think, given the way things look to be going for Subversion uptake, that a few years from now Eclipse only supporting CVS, and forcing you to go to third parties for Subversion support, would have been akin to MS shipping Windows XP with only support for NetBEUI, and forcing users to go to third parties for TCP/IP support. See also the discussion in this thread: http://www.eclipsezone.com/eclipse/forums/t55426.html Bug 71735 pretty much sums up the situation regarding Subversion support in Eclipse (i.e. the decision would come from the PMC). Why does this bug depend on bug#71735? It makes no sense having to wait for eclipse to convert to subversion for a default svn implementation to be available in eclipse. Not to be rude or anything but I don't think it is wise to ignore subversion as it is gaining a lot of momentum at the time. My point is that I am not in a position to make the decision as to whether Subversion support ships with Eclipse. If Subversion did become part of Eclipse, it would be a separate component from Team and CVS. The decision to create this component needs to be made by the PMC. One possible motivation would be to support Eclipse projects that want to use Subversion (hence the relationship to bug 71735). I am adding this comment as it will make the search that led me here more fruitful for other users. Installing the Subclipse plugin can be a bit of a pain and I must admit it is fairly un-documented (at least in any easy to find documentation) The following link will, hopefully, prove useful to others. http://dev2dev.bea.com/pub/a/2005/11/subclipse.html (In reply to comment #53) > Installing the Subclipse plugin can be a bit of a pain and I must admit it is > fairly un-documented (at least in any easy to find documentation) > > The following link will, hopefully, prove useful to others. > http://dev2dev.bea.com/pub/a/2005/11/subclipse.html Glad you liked the article, but I think Subclipse does have more or less consistent end user documentation. (In reply to comment #53) > Installing the Subclipse plugin can be a bit of a pain and I must admit it is > fairly un-documented (at least in any easy to find documentation) The documentation is all in the Eclipse online help. Is that really hard to find? Where else would you look for it? Installation is difficult? Did you read the detailed install instructions? http://subclipse.tigris.org/install.html It installs like most Eclipse plugins should and if anything we usually get compliments on the detailed instructions. Not that I believe it's going to make any difference to this bug, but SourceForge.net has just officially announced that it offers SVN support (after beta-testing it for a while). The announcement is at: https://sourceforge.net/forum/forum.php?forum_id=544829 Apart from anything else, there's no delay between the 'head' and what's available by anonymous access (with CVS there's a delay on their setup) and they provide 'rsync' access to mirror the entire repo back to off-site backups. This might enable mirror services to offer not only binaries but also source access to the version control system. Not that it really matters here, but more people are moving (in the open-source community, as well as business) away from CVS to SVN. CVS will still be around for years, but new projects aren't being started in CVS in droves. Even more tellingly, both JDT 'competitors' to Eclipse are offering subversion support out of the box now or in the near future: http://vcsgeneric.netbeans.org/profiles/index.html (Subversion support available from update center for Netbeans 5.0) http://www.jetbrains.com/idea/features/newfeatures.html#subversion (Subversion built in to IntelliJ IDEA 5.0) The action (or rather, inaction) on this bug seems to be a 'Somebody Elses Problem'. Nothing to do with Team, ask PMC. PMC need the support on the OS. The OS doesn't have Subversion. Projects can't use Subversion until there's a plugin. The plugin isn't going to get put here until there's subversion support from Team. Repeat as necessary. Mark (et al) are doing good work where they are on the subversion plugin. No-one expects Eclipse to move everything over to SVN internally, or even take resources off an existing team. But pretty much everyone (on this thread) thinks that it would be good if the subversion support came from the Eclipse community on Eclipse.org. It's obviously not going to be as feature-rich as the CVS plugin is now from day one, but it won't grow if there's no support either. There's an incubator process for projects like BIRT; how come Eclipse PMC can't find time to make part of that available for Subclipse/JavaSVN? Heck, even integrating it into the nightly build process and having the automated reports would be good. It's not even as if there's no precedent for shipping individual parts. The FTP and WebDAV plugins are available as a separate downloadable feature from Eclipse.org, and have been for a while. What's so difficult about making Subversion be one of them too? Maybe the PMC can comment on why it's so difficult to bring the subclipse plugins into Eclipse and have Mark and others from the community work on it. I don't think anyone's suggesting that Team should necessarily own it (or even work on it), or that it's a precursor that Eclipse.org moves all of its own projects over to subversion before this happens. All that's really needed is a little space for subclipse to live on eclipse.org, under an EPL (I'm sure that relicensing it should be possible), and for the current set of developers on Subclipse to get the ability to continue developing it here. This bug has already lasted past one EclipseCon; it's heading for two. Let's not turn it into a hat-trick. I guess I just don't understand why this is such a problem (to implement, not to request). A fantastic subversion implementation already exists in Subclipse. Granted, there are a few rough spots, but basically all that would have to be done is go with Eclipse standard style icons and better status messages and away it goes. Chances are, that would be number 2 on the agenda having added subclipse as an eclipse.org project. Alex is right that Eclipse competetors are supporting this, why shouldn't Eclipse? In fact, Eclipse users are being drawn away in part because of the integrated SVN support. For that matter, NetBeans and IDEA had SVN support two releases ago. Now they have Visual Age integrated into *the base install.* Eclipse is falling behind in this respect, quite frankly. And even though Eclipse's CVS support is still quite a bit ahead of both IDEs, a lack of SVN (if nothing else) is making the entire community look bad. ANNOUNCEMENT: Subversive - Eclipse client for Subversion
The Subversive project is a brand new Eclipse plug-in which provides Subversion support. From a user point of view, Subversive provides Subversion support similar to CVS support, which is already part of the standard Eclipse platform. The main use cases, which are familiar to CVS users, are:
* Connection to Subversion using different connection methods
* Repository browsing and modification
* Checkout
* Synchronize
* Commit
* Update
* Resolve conflicts
* Add to list of ignored resources
JavaSVN open-source library is used for interaction with Subversion. After comparison with other tools that use JavaSVN, the Subversive team together with the JavaSVN team extended standard Subversion API. This improvement gives Subversive an advantage compared with other native and Java-based Subversion clients. The following solutions, now available in Subversive, are not present in other Subversion clients because of its standard API limitations.
A more detailed feature set could be found here:
http://www.polarion.org/p_subversive_features.php
You can download it for [u]free[/u] from:
http://www.polarion.org/p_subversive_download.php
Please report your experience, wishes, improvements in dedicated Subversive Forum on our community site:
http://www.polarion.org/p_subversive.php
(In reply to comment #58) > http://www.polarion.org/p_subversive.php Thanks for the anouncement here. On the website it's stated that the license is Open Source. However, I wasn't able to locate ANY reference to the source code or the source repository. The source is also NOT included in the binary downloads. So, what das Open Source license mean? I'd also like to know why this is better than Subclipse and if it's compatible with 3.2 M5 (which subclipse apparently isn't)? Granted, the icons are vastly superior (more Eclipse-like), but is there any other reasons? (In reply to comment #60) > I'd also like to know why this is better than Subclipse and if it's compatible > with 3.2 M5 (which subclipse apparently isn't)? Subclipse supports 3.2M5. There was just an issue with the checkout process due to a change made in Eclipse scheduling rules. This was quickly resolved with the 0.9.108 release of Subclipse. My mistake. Sorry. :-) Incidentally, Subversive (so far) has been faster and more professional looking than Subclipse. However, when I switch from the SVN Repository perspective back to the Java perspective and attempt to open the Package Manager from it's docked position, I get a widget disposed error on the workspace and have to restart Eclipse. Also, there is no support for 'Import project from SVN' which is annoying. Also, the Commit and Update menu items need to switch places to maintain the interface convention with the CVS support. I realize this really isn't the proper forum for this. If someone could direct me to the right place to do this I'd be more than happy to post there instead of here. :-) Oh, my only problems with Subclipse are icon professionalism (they could use a once-over) and speed in repository actions. Subversive is more professional and vastly faster (think a factor of 10), but it's less stable. Oh, it does have a nice feature in it's design which allows for automatic addition of the project into the trunk/ directory whereas subclipse will put the project (by default) in the root of the repository. Subversive seems to handle this (as well as Tags and Branches) much better in its interface. (In reply to comment #62) > I realize this really isn't the proper forum for this. If someone could direct > me to the right place to do this I'd be more than happy to post there instead > of here. :-) There are links for forums and mailing lists on the same page that you download Subversive from. The Subclipse mailing list is users@subclipse.tigris.org. > Oh, my only problems with Subclipse are icon professionalism (they could use a > once-over) and speed in repository actions. I actually think the Subclipse icons are really first-rate. Most of them came from TortoiseSVN and there are several Subversion clients that have asked them for their icons. Regardless, this is not the place for this discussion. If you have issues with Subclipse then the users@ mailing list is the place to discuss them. Also, Subclipse is open source. If you do not like the icons then submit new ones and build a consensus in favor of them on the mailing list. I wish I had the artistic talent to submit new icons. :-) Actually, I think you should just drop the icons in the Team menu (with the exception of Synchronization and branching/merging) to keep with the convention layed down by the CVS support. All the other icons do look pretty good. (with the exception of the label decorators not drawn from Eclipse) If the majority thinks that the Subclipse icons look good, then I bow to the masses. :-) Personally, I never cared for the Tortoise(CVS|SVN) icons. I really miss being able to use the Quick Dif feature with Subversive. Ben Ben, slightly off topic, but are you planning on moving RSSOwl's version control over to Subversion now that it's supported by SourceForge? Daniel: I think not for RSSOwl 1.x. For the new RSSOwl 2, we already work with Subversion. Currently that is hosted on JavaForge. We think about moving to SF, as it comes with nice additional features like CIA. Ben Btw CIA, for those that don't know about it yet, is a service that hooks into a system like CVS or SVN and keeps a history-overview of checkins. Recently Eclipse was added. See http://cia.navi.cx/stats/project/Eclipse Ben (In reply to comment #68) > Btw CIA, for those that don't know about it yet, is a service that hooks into a > system like CVS or SVN and keeps a history-overview of checkins. > Recently Eclipse was added. See http://cia.navi.cx/stats/project/Eclipse BTW, to some extend it is possible to see such updates right in Eclipse Synchronize view, just run a comparisin between date tags and it would give you change sets from for that period. That's true, but only if you have the components in full source in the workspace. CIA has the advantage of aggregating changes of the entire project. Btw, other features of CIA include IRC and Mail notification. Sry for offtopic btw =o) Ben (In reply to comment #70) > That's true, but only if you have the components in full source in the > workspace. CIA has the advantage of aggregating changes of the entire project. Nope. You can run comparison right from Repositories view. Subclipse actually provide similar information just in history view. Though no filtering by dates. Thank you, Daniel. >Commit and Update menu items need to switch places This will be done with Subversive 1.0.0.M7 >no support for 'Import project from SVN' We scheduled this task after critical problems will be fixed >widget disposed error We will check this problem ASAP. Best regards, Subversive team. Thank you for report, Benjamin.
>I really miss being able to use the Quick Dif feature with Subversive
We understand this feature is blocker and we will add it in the nearest time.
Best regards,
Subversive team.
I have a simple question for Polarion and the Subversive team: Why? Why was it necessary to create a new SVN client for Eclipse, especially when the license appears to be the same (based on the click through) and has many of the same features (some screens identical)? As a developer of Subclipse I am interested to know why you thought it would better serve the community to create a competing product instead of trying to improve on what is already out there. Sure, Subclipse is far from perfect, but it is only supported by a very small number of people (really just one). If the Subclipse and Subverive teams had joined forces, we could have produced a better subversion client (based on whoever's codebase) which would have made everyone happy. I am sure that if Polarion had offered to lead a subversion project at eclipse.org we probably would have signed up. The fact that there was no communication from Polarion about their intentions up until an announcement was posted on the subclipse mailing list was most curious, especially for an Open Source project. (In reply to comment #59) > (In reply to comment #58) > > http://www.polarion.org/p_subversive.php > > Thanks for the anouncement here. On the website it's stated that the license is > Open Source. However, I wasn't able to locate ANY reference to the source code > or the source repository. The source is also NOT included in the binary > downloads. So, what das Open Source license mean? > Dear Gunnar and others, Subversive is Open Source product and we will deliver the source code together with binaries since 1.0.0 release, which is planned in couple of weeks. The reason behind source code absence in current builds is infrastructure preparation. We will use Polarion server for project hosting which will cover all project aspects - SVN repository, issue tracker, builds, web access to SVN. Best regards, Igor Vinnykov Subversive team Can you please move Subversive-specific discussion to a more appropriate forum? The announcement was OK, but everything after that feels highly inappropriate for an eclipse bug report. Thanks. I've been using Subversive since it was released. It's absolutely fantastic. Great plugin. As far as stability, it still doesn't quite measure up to Subclipse but it's getting there. A 1.0 release is schedualled for the end of the month and I'm anticipating most of the bugs (and all of the known stability issues) will be fixed by then. I'd like to recomend Subversive for inclusion as an Eclipse.org project rather than Subclipse (partially because a main goal of Subversive is to be included as a core project, and Subclipse seems to be content to remain hosted on Tigris). Is there any way we the community can influence this process or make an official nomination for an Eclipse.org project? (In reply to comment #77) > Is there any way we the community can influence this process > or make an official nomination for an Eclipse.org project? If the Subversive developers are really interested in pushing their project to Eclipse.org then they will need to propose this project because it's their project and their code contribution. We (the community) will have to wait till this happens. (See http://www.eclipse.org/projects/dev_process/ section "The Project Lifecycle"). Once Polarion proposes this, how precisely can we the community influence the decision (the page you linked was a little vague on this). First of all, the Subclipse developers should be convinced to try this. As it is, they haven't even considered this approach. They are already completely occupied by writing the Subclipse plugin. So I suggest whoever wants to help this effort to join the subclipse mailing list and offer your help to create and maintain this new project. Well, I think at this point I don't want Subclipse to be included. I wanted it before because it was the only option, but I really like Subversive much better. I have to agree with Mark that it has numerous faults, but it's faults are in more tollerable places. :-) And considering the holy wars which have been fought on forums and blogs about the respective virtues of the two plugins, I'm not sure the consortium is going to hasten to so obviously choose sides as to include one or the other. (In reply to comment #81) > Well, I think at this point I don't want Subclipse to be included. I wanted it > before because it was the only option, but I really like Subversive much > better. I have to agree with Mark that it has numerous faults, but it's faults > are in more tollerable places. :-) And considering the holy wars which have > been fought on forums and blogs about the respective virtues of the two > plugins, I'm not sure the consortium is going to hasten to so obviously choose > sides as to include one or the other. I not sure what Subclipse faults are being referred here, but I find Subclipse development much more open and community friendly. Joinig the Eclipse org sounds easy, but there are several factors that need to be taken into consideration: 1. Subversion has a very lively release schedule (compared to CVS) that does not coincide with the eclipse plaform release schedule. This means that people using only 'final' releases of the platform will be 1 to 2 releases behind in SVN features. 2.There is absolutely no SVN infrastructure at eclipse.org (bug 131096) and there is no ETA for it. It wouldn't make much sense to put the code for an SVN plugin an a CVS repository... 3.Team/CVS have said they will not be able to contribute due to lack of resources, so there will be no extra resources working on it 4. There are serious licensing concerns with shipping libraries such as JavaSVN as it does not have an EPL compatible license. It is ok for a user to download, but not ok for people building applications on top of the SDK (like RAD) The only benefits i can see for becoming an eclispe project is greater exposure and a better out of the box experience for end users. Are there others i am missing? If a project is created to add SVN support it should be used as an opportunity to build SVN infrastructure for other projects that wish to switch from case as well as becoming a second reference implementation for the Team framework (which is currently very CVS specific). It's good to see some movement on this. One minor nit: I think many of the places it says "Subversion" in that proposal, it meant to say "Subversive". For example, "The Subversion project was started in the second quarter of 2005 and will reach its first release on polarion.org during the third quarter of 2006." Just to play the devil's advocate, but is Subclipse in consideration anywhere here? Obviously, they'd have to submit a request themselves. But if they did, would this become a Subversive vs Subclipse war among the Eclipse board? Well if you read the proposal it says: "Potential candidates for joining the project could be the Subclipse development group, the Smart SVN development group, and others. We have contacted the Subclipse development team with an offer to join the Subversion* project. We plan to invite current Subclipse committers/contributors to join Subversion* on eclipse.org" * I think they mean Subversive here. Although, come to think of it, if the project were were called something that is neither "Subversive" nor "Subclipse" it might help address any hard feelings. FWIW, I'm not on either team, I just would like to see SVN support in the Eclipse SDK. Something intentionally anonymous and general might be better as a name if it is targetted to be included in Eclipse anyway, like "Subversion Team Support" or "SVN Team Support". The main CVS plugins are called "CVS Team Provider Core" and "CVS Team Provider UI". Perhaps the closer the SVN plugins are to the CVS plugins the more likely they are to be accepted into Eclipse proper. Thanks to Gunnar Wagenknecht for finding and publishing a link to the Subversive proposal on the eclipse.org. Unfortunately there is an annoying 'bug' in DOC->HTML transformation, so in all places except the first chapter, the word Subversive was replaced by the word Subversion. It’s our fault, sorry for that. We will make our best to fix it soon. Nonetheless, we are glad to see SVN community interest in the SVN client proposal on eclipse.org. Our proposal is a first step towards including SVN support into standard Eclipse distribution. Of course there is a long way to go; we are ready to invest maximum effort. Any help from SVN and Eclipse community is welcome. Please feel free to share your opinion and technical ideas. Best regards, Igor Vinnykov Polarion Team The Subclipse team is also working on a proposal and will be submitting it in the coming weeks. We have been concentrating on our Eclipse 3.2/Callisto release which is coming together nicely. http://subclipse.tigris.org/callisto.html I have no idea what the Foundation does when there are two competing proposals. There is no reason to think it will be a war though. As for the name, I'd agree that ultimately, if it becomes part of Platform, it would make the most sense to just refer to it as the SVN support, similar to how CVS is referenced. Not much of a reason for a special name. I think both Subversive and Subclipse are merely using the existing project names to indicate where the code contribution will be coming from. All that being said, I think tbe points that Brock raised in Comment #83 are the ones the Foundation really needs to consider. There are two good code bases to work from here, the real challenge seems to be getting the existing resources of the Foundation on board with getting this support into the Platform component where it belongs, and all of the things that go with that, such as providing SVN hosting for projects and integrating SVN into the releng process. (In reply to comment #90) > I have no idea what the Foundation does when there are two competing proposals. I thinks it's very likely that the Foundation will start/continue/enhance the dialog with both projects. Actually, it's a very good situation because it reflects the interest and the support for Subversion support in Eclipse. I really, really hope, that TMate would join too and contribute their JavaSVN library. As far as I remember, any JNI based interaction with Subversion is likly to get a NO-GO for a possible Platform integration. (In reply to comment #91) > I really, really hope, that TMate would join too and contribute their JavaSVN > library. As far as I remember, any JNI based interaction with Subversion is > likly to get a NO-GO for a possible Platform integration. I do not know what there plans are, but TMate would have to be changed to EPL for the Subversive project to be an Eclipse project. As I understand things, Polarion is negotiating with TMate to change the license. As for the JNI issue, all I'll say is thank god that wasn't the case when SWT was developed. I'll not say any more as the 100+ people subscribed to this bug probably are not interested and this is not the best place for a discussion on the merits of using the Subversion API. First, off, I don't know why the native-Java implementation (JavaSVN) exists when JavaHL does but here are a few thoughts from the receiving end: Eclipse contains a Java CVS client. This causes all kinds of griefs, especially that many CVS server versions don't play well with it. When you're using a CVS server, you better have one which matches the Eclipse CVS client, or you'll have all kinds of problems. I've yet to see someone lose their work, though. Subversion has a Java API which is supported by the SVN team. As I see it, there are two drawbacks: 1. The API doesn't expose all the things necessary to build a performant Synchronize view 2. You have the same DLL/shared library problems as with SWT. My comments: The SVN team is a very active one. They are helpful and quick and I would like the Java API in the SVN project be improved rather than doing the work twice ... err ... four times: The SVN team has one API, Subclipse had two (DLL, commandline) and now, there is JavaSVN. Who can say something about the options race we're opening here? How fast will changes in the SVN API be reflected in JavaSVN? They seem very active now. Is that just a sprint or will this stay? I'm a fond user of Subclipse but there, we users were locked to old versions of Subversion for a long time because the developers simply lacked the time to migrate to the new version. And while the DLL/shared lib problem does look ugly at first, I think SWT has proven that it is possible to deliver JNI code along with the product. It takes a bit of care but it's definitely an option which we shouldn't rule out carelessly. Maybe this would even lead to a new portability leap in the Java world: Eclipse could be delivered with DLLs for *every* OS (ie. one download which is a few MB bigger) and select the correct ones at runtime. Or imagine a wrapper class which can load a shared library on your system and call functions in it (something like JNI-on-demand). As it is, I'm not convinced that duplicating the development effort of the SVN team is the best option. (In reply to comment #93) Aaron, I think I am in agreement with your main points. One of the biggest reasons why SVN was created was that CVS did not have an official library interface to it. Everyone just had their own versions of CVS that engineered the protocols. The SVN developers wanted to create reusable libraries. One of the reasons they wrote SVN in C is that C libraries can be reused by the most other languages, and there are rich language bindings for Python, Perl, Ruby and Java among others. Since all SVN clients use the same libraries, you have great interoperability and compatability, and generally do not need to worry about switching from client to the next as your work on a project. > Subversion has a Java API which is supported by the SVN team. As I see it, > there are two drawbacks: > > 1. The API doesn't expose all the things necessary to build a performant > Synchronize view This is not true. We are not waiting for any specific changes to the library. There were some enhancements made to the Subversion API by members of the Subclipse team. These enhancements made it into Subversion 1.3. Technically, these enhancements were needed in Subversion itself, once they were made, JavaHL just had to leverage them -- which it did in 1.3. > 2. You have the same DLL/shared library problems as with SWT. True. > My comments: The SVN team is a very active one. They are helpful and quick and > I would like the Java API in the SVN project be improved rather than doing the > work twice ... err ... four times: The SVN team has one API, Subclipse had two > (DLL, commandline) and now, there is JavaSVN. Subclipse does not have its own API. We use JavaHL. By and large, JavaHL is developed by members of the Subclipse community. I am one of the handful of committers for JavaHL, and a co-worker of mine is a full committer for Subversion and has been making general improvements to Subversion that will help Subclipse (such as those 1.3 changes). > Who can say something about the options race we're opening here? How fast will > changes in the SVN API be reflected in JavaSVN? They seem very active now. Is > that just a sprint or will this stay? To this point, it has not been an issue. But I agree, there is a very real possibility that this could be a problem in the future. > I'm a fond user of Subclipse but there, we users were locked to old versions of > Subversion for a long time because the developers simply lacked the time to > migrate to the new version. This comment is the main reason I even bothered to reply. Subclipse users have NEVER had to wait for a long time. With the exception of people stuck back on the Eclipse 2.x code base. I have generally issues Subclipse releases on the same day, or within a couple of days of a Subversion release. Even the minor fix releases. I thoroughly test the Subversion release candidates with Subclipse and am somewhat proud that I found the bugs that caused them to scrap 3 of the release candidates on the way to the 1.3 release. Now, the converse to this is true. Because new Subversion releases tend to include features we wanted in Subclipse, we tend to make our users use the most recent versions of the Subversion libraries. This is mainly an issue for Linux users that rely on their distro to obtain the libraries. > And while the DLL/shared lib problem does look ugly at first, I think SWT has > proven that it is possible to deliver JNI code along with the product. It takes > a bit of care but it's definitely an option which we shouldn't rule out > carelessly. I agree. JavaHL got a bad rap when Subclipse first started years ago because it was hard to build the library. So Linux users had a real hard time getting it. We have included the library for Windows for a long time, and there are no issues at all on Windows. On OS X, there are a couple of very simple ways to obtain the library, so the only real issue on OS X is pointing people at those installers. Linux seems to be less and less of an issue. It is now pretty easy to build Subversion and JavaHL. Most people do not seem to have trouble. Also, all of the major distros are now doing a good job with this and include the JavaHL library. You can get it via the normal packaging system with Ubuntu/Debian, Fedora and SUSE. I think the older RHEL distros might still only provide an old package, but there are plenty of other places you can get an up to date one. With the right Linux expertise it might even be possible to include the library with Subclipse, the way we do on other platforms. > Maybe this would even lead to a new portability leap in the Java world: Eclipse > could be delivered with DLLs for *every* OS (ie. one download which is a few MB > bigger) and select the correct ones at runtime. I do not know if you mean Eclipse or Subclipse, but this is already technically possible. We provide the Windows binaries in a way that Linux and OS X are smart enough to not download them. If we could provide working binaries for Linux and OS X, we could just drop them right into the same framework and it would all just work. That being said, it seems like there is a trend starting on Linux for the distros to provide Eclipse and plugins in their own packaging systems. I have worked a bit with teams from Debian and Fedora that are now providing Subclipse this way. I made some changes in the Subclipse packaging to help them with this. When you obtain it via their systems, JavaHL can just come with it and be installed correctly to just work, or it will when they are finished. This reply has gotten too long, and I said I would not do this, so I'll just cut it off here. I mainly wanted to correct a couple of points you made about Subclipse. Thanks Re: comment #94: I hope you didn't get my comment as a critic of the Subclipse project; my intention was to point out that there is a user (consumer) side to the issue. So the main goal for this bug shouldn't be which project to choose but to make sure that the final result will be usable for end users without grief: - Linux users shouldn't need to download extra packages or have to compile them. - Users shouldn't have to worry which version of SVN is installed on their computers -> any version 1.3 should work; I think with how SVN tries to keep versions compatible, this should be relatively easy to obtian. If all else fails, it might be an option to include all Subversion libraries to make sure that SVN works out of the box, no matter how strange/broken a users' setup might be. - Admins should have an easy time to setup SVN servers (version wise; unlike CVS where not all 1.11.x versions can be used with Eclipse). (In reply to comment #95) > Re: comment #94: > > I hope you didn't get my comment as a critic of the Subclipse project; my > intention was to point out that there is a user (consumer) side to the issue. No, I did not take it that way. I just wanted to clarify a few things. > - Linux users shouldn't need to download extra packages or have to compile > them. I agree this should be the goal. It does potentially fly in the face of your argument that seemed to be in favor of JavaHL over JavaSVN. I think the technical hurdles should be solvable, but a few people that know more than me have said they are not. > - Users shouldn't have to worry which version of SVN is installed on their > computers -> any version 1.3 should work; I think with how SVN tries to keep > versions compatible, this should be relatively easy to obtian. If all else > fails, it might be an option to include all Subversion libraries to make sure > that SVN works out of the box, no matter how strange/broken a users' setup > might be. Unless you are saying it does not matter if they have 1.3.2 or 1.3.0, which is true, then this one is impossible. If you are using another library, you are always going to have version dependencies. > - Admins should have an easy time to setup SVN servers (version wise; unlike > CVS where not all 1.11.x versions can be used with Eclipse). This is the one that should make the previous one a non-issue. Subversion has a great record in this area. Clients and servers are backwards and forwards compatible. Period. As long as we are using the Subversion libraries, there should never be an issue where the server needs to be modified, unless some new feature is desired. For example, Subversion added locking in 1.2. If a Subclipse user tried to lock a file against a 1.1 server, they would just get an error message that the server does not support locking. But other than things like that, the libraries always know how to negotiate their capabilities with one another. The point being, I do not think it is imposing any great difficulty on the end user to have to be using the latest version of the libraries. In reply to comment #194 > JavaHL got a bad rap when Subclipse first started years ago because > it was hard to build the library. So Linux users had a real hard time getting > it. We have included the library for Windows for a long time, and there are no > issues at all on Windows. On OS X, there are a couple of very simple ways to > obtain the library, so the only real issue on OS X is pointing people at those > installers. > > Linux seems to be less and less of an issue. It is now pretty easy to build > Subversion and JavaHL. Most people do not seem to have trouble. This is one of the main problems I've had with the subversion developers for some time. The assumption is that since it's written in C, everyone has the time/inclination to grab the latest-and-greatest from CVS and build it themselves. It doesn't seem to occur to them that some people might want to use a version system *as a tool* rather than as an exercise in 'make; make install'. Java is an excellent example -- it's possible to write a Java project without wanting to touch any other language/system to make it work. At least the CVS client (and SSH support) is already compiled and built for me and available for me to use. (Not everyone has a C compiler installed, either, nor needs one, especially if you're doing Java/Python/Ajax/Ruby/Pretty much any other language or requirement for a versoning system) The big problem (for me) is that as an OS X user, I'm accustomed to things just working. I don't see a Subversion plugin for Eclipse as something that I should have to download and install external tools just to make the plugin work. I'm not directed to http://www.eclipse.org/swt/ before I can use some plugin that relies on SWT; it's part of the core system that I'm using. A subversion library that makes me go and download external tools to get working isn't 'out of the box support'. And the other thing that Subversion gets wrong is that each of the builds are hosted and maintained by different organisations. If you go to the subversion website, there's links to random other websites that have compiled builds (which may be out-of-step with the current version. The Mac OS X build using Fink is both (a) horribly out of date in the binary build, and (b) behind with the download-it-yourself-from-source build. Even the non-fink one is out-of-date; Subversion 1.3.2 was released on May 31, and the Metissian website (http://metissian.com/projects/macosx/subversion/) still only has 1.3.1. Compare that to any other open-source effort (Eclipse, Apache etc.) and the key difference is that *they* build and host (possibly via mirrors) the pre-build downloadables. It's much easier from a corporate acceptance point of view to go somewhere known than some random person/companies web page to download a binary. Even though most consider SVN to be better than CVS, some of these issues are inhibiting as fast adoption because the support is all about the developer, rather than the user, community. Frankly, it doesn't bother me whether a plugin has native code or not, as long as it works out-of-the-box and I don't have to go anywhere else to download or install external packages to make it work. You don't see Eclipse suggesting that you go and download the Ant libraries if you want to run a build-file; it's provided. I do think that it makes sense to have a Java rather than native API if either are available, because it's a lot easier to support one library than many versions. For example, the JavaSVN would have worked fine on a MacIntel box but the subclipse libraries didn't (until Metassian updated the 1.3.1 build). SWT goes to a lot of work to compile-and-test for every different platform that is supported by Eclipse; and if the native route is chosen, so should the subversion plugin developers. Alex, I appreciate your points, but I think you are wrong on some of them. I can only think of two major open source projects that work the way you say. Eclipse and Firefox and the latter has mostly changed on this too. On Linux you get your open source applications from the distro, not from the producer. Here is the download page for Apache: http://httpd.apache.org/download.cgi Where is the binary download for Unix or OS X? Subversion does not expect users to build from source, but on Unix it is pretty common that users want to, so it strives to make this easy. The real issue with Subversion was that it was new and it took a release cycle before the distributions started to include it. You get CVS for OS X because Apple included it. It is not the fault of the Subversion developers that Apple does not include Subversion. Subclipse would gladly provide the binaries for other platforms. I personally build JavaHL on Windows and Linux and test on Windows, Linux and OS X. The issue is just that there are technical issues that so far prevent distributing the libraries as a plugin. Eclipse has some of the same problems, and in some cases they cheat. For example, SWT needs the Cairo library on Linux but it cannnot put it in a plugin or SWT would not find it, so they include it in the Eclipse root folder. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=90926#c8 This is not an option that a third party plugin is offered via the Eclipse Update Manager. If Eclipse provided a way for plugins to install libraries into a folder that was included in LD_LIBRARY_PATH on Linux we would probably not have any issues delivering the binaries. Subversion happens to have a particularly bad structure for Eclipse, because it is built on several common libraries (APR, Neon, BDB, OpenSSL etc..). So a Subversion plugin would have to provide all of these binaries. The problem, as I understand it, is getting all of these libraries to be found at runtime if they are not in the Java library path. Subversion lets you do a static build, but from what I was told, when Java loads a library for a JNI call on Linux, it does something that "overrides" the static nature of the build and causes all of the libraries to be looked up dynamically. If we could just provide a static library, this would be simple. I do not pretend to understand why this is the case, but a Debian developer explained it to me once pretty convincingly. Personally, I would think SWT would have had most of these issues too, but maybe the libraries it needs, such as GTK2 are guaranteed to be in the right path. Actually, that brings up a good point. If you do not have GTK2 installed, then SWT does not work. It is only because those libraries are so commonly installed that this is a non-issue. So it is not really fair to hold up SWT as this great example of perfection, because the reality is that they do not do anything to make this work for you, they rely on the libraries they need being available. The real difference is that the libraries that SWT needs are mostly commonly available. The good news is that Subversion (including JavaHL) is now easily available in binary form for each operating system. In the case of Linux, it should show up in your package manager and install relatively easily, assuming it was not installed by default. For OS X, the best option is the Metissian download. Apple added Subversion support to XCode, but as far as I know, Apple does not provide the Subversion binaries, you still need to get them yourself. Finally, JavaSVN is a great library, no questions about it. But it is still largely one man's efforts to reverse engineer the Subversion libraries. Are all users going to be comfortable with that? Subclipse allows the user to choose the best option for their needs. Does everyone want to make a choice? No, of course not. Subclipse automatically falls back to JavaSVN if JavaHL is not available, so for the most part users do not need to make a choice. Of course if we had to ship Subclipse without JavaSVN because of the EPL issues, then we would have to improve this with some kind of UI that directed the user to download JavaSVN or go install the JavaHL library. I think that is all solvable. Of course the ideal would be to provide JavaHL binaries for each OS in a manner that the plugin will find them. The libraries themselves are all thoroughly tested on each of Eclipse's platforms, the issue is just figuring out how to distribute them. To answer your question, there's a bunch of binary downloads for other operating systems: http://mirrors.dedipower.com/ftp.apache.org/httpd/binaries/ Unfortunately not all of them are up to date either -- and that's the problem with native libraries. Subversion was designed (as you say) with a clean API between client and server; in fact, one of its advantages is that it can run transparently with HTTP and WebDAV requests. So why does the implementation language of the client side matter? Surely one of the reasons that the web has worked is because there's a protocol between client and server rather than needing to hook specific APIs. I'm pretty sure that Firefox isn't limited to having to compile against CommonsHTTP just because it's a library to use the same API. Bottom line; there's no downside to a Java implementation on the client (which will work everywhere and avoids the problems that you enumerate) other than one of support. Get JavaSVN as EPL, folded in with this plugin, and there'll be a much larger base for supporting. The problem is that SVN developers have this clouded view that every developer has a C toolkit installed. Guess what -- there's more languages than C out there. On the other hand, I can go and get pretty much any Java package (tomcat, jboss, james) and it works out-of-the-box. Don't forget that Eclipse is more than a Java IDE -- there will be lots of non-developer users for working with data, reporting, testing etc. -- and they need to have version control too. (In reply to comment #99) > Subversion was designed (as you say) with a clean API between client and > server; in fact, one of its advantages is that it can run transparently with > HTTP and WebDAV requests. So why does the implementation language of the client > side matter? It is true that Subversion CAN use http/DAV for its protocol. But using just the standard protocols you cannot do anything that you would call version control. The real Subversion stuff happens using the http REPORT method which essentially makes it a custom protocol riding on top of http. When it initially started the plan was to work towards something called DeltaV which is like the second version of WebDAV. Tools like Eclipse could have a generic DeltaV client in them and talk to any version control server that implemented DeltaV. The reality is just that none of this ever materialized to the point that it worked. > Bottom line; there's no downside to a Java implementation on the client (which > will work everywhere and avoids the problems that you enumerate) other than one > of support. There is a lot more to JavaSVN then implementing the protocols. The real difficulties are in the client-side working copy management. This is where most of the work resides so that the protocols can be implemented and this is where it is difficult to remain compatible. Just think of how the Eclipse CVS client did not used to play well with other CVS clients when working on the same workspace. So far, JavaSVN has done a good job of doing this in such a way that it is compatible with other SVN clients. > Get JavaSVN as EPL, folded in with this plugin, and there'll be a > much larger base for supporting. If only it were that simple. Why should the people that created JavaSVN just give it away? I think they have already sold quite a few commerical licenses to other people that use it for Subversion clients, such as the IntelliJ plugin, SmartSVN and Polarion. Once JavaSVN is EPL anyone can take it to build commercial products so they are going to want to be compensated enough to make this worth while. They obviously have invested a lot in creating this library. > The problem is that SVN developers have this clouded view that every developer > has a C toolkit installed. Guess what -- there's more languages than C out > there. On the other hand, I can go and get pretty much any Java package > (tomcat, jboss, james) and it works out-of-the-box. This seems unnecessarily hostile. Not to mention that it is untrue. > Don't forget that Eclipse is more than a Java IDE -- there will be lots of > non-developer users for working with data, reporting, testing etc. -- and they > need to have version control too. I assume your point here is that it needs to work out of the box. I agree, that is the goal. I am trying to explain what some of the issues are so that hopefully we can work towards a solution. What I object to is this notion that we are somehow stupid or lazy because it all does not just work, when things like SWT do just work. In apologies to comment #100 > What I object to is this notion that we are somehow stupid or lazy because it all does > not just work, when things like SWT do just work. If that's how it came across, I apologise. I didn't intend for it to be interpreted that way. But I did want to try and highlight some of the issues so that we can work towards the solutions, so like you say, it will just work out of the box. > Finally, JavaSVN is a great library, no questions about it. But it is
> still largely one man's efforts to reverse engineer the Subversion libraries.
Just an insane idea: Would it be possible to write the client part of Subversion in a C-like language which can be translated to C and Java?
Or, the other way round, how about an automated translator from C to Java? As far as I could see, the SVN source code is pretty clean and doesn't use many dirty C tricks (like directly working with void pointers).
That would allow to have one code base from which the Java client could be generated and thus keeping both versions in sync without needing DLLs inside of Eclipse at the cost of additional work on the Subversion side.
For those that did not notice yet: http://www.polarion.org/index.php?page=eclipse&project=subversive http://www.eclipse.org/subversive/ Reopening to reassign (In reply to comment #100) > When it initially started the plan was to work towards something called > DeltaV which is like the second version of WebDAV. > ... > The reality is just that none of this ever materialized to the point > that it worked. I just wanted to comment that it seems full DeltaV has been implemented since SVN 1.2. Check http://svnbook.red-bean.com/nightly/en/svn.webdav.autoversioning.html Regarding comment #105, Subversion does not implement the full Delta V spec. As indicated in the link provided by Mladen, Subversion implements auto-versioning. Auto-versioning is quite useful for less technical version control users, and even for more techincal users who simply mount a Subversion repository as a file system (or Windows "web folder") to take advantage of easy snapshotting. How hard would it be to adapt the subversion team provider to work with WebDAV servers (I'm thinking Apache Jackrabbit, but maybe also Xythos)? I know there's a WebDAV plug-in but it doesn't have nearly the functionality of the subversion plug-ins. (In reply to comment #107) > How hard would it be to adapt the subversion team provider to work with WebDAV > servers (I'm thinking Apache Jackrabbit, but maybe also Xythos)? I know there's > a WebDAV plug-in but it doesn't have nearly the functionality of the subversion > plug-ins. This may be off-topic, but a full EFS WebDAV implementation is in the works. http://wiki.eclipse.org/index.php/WebDAV_EFS_Implementation Hello Eclipse Community, We are pleased to announce a Subversive Web page at Eclipse.org: http://www.eclipse.org/subversive. At this Web page you can find information about both Subversive streams (1.0.x and 1.1.x) and moving the project forward. I'm removing the dependency from bug 71735. That bug requests the Eclipse project switches to SVN, which IMHO is quite irrelevant to SVN support in Eclipse itself. Can this bug be closed yet? Wondering if there's a way of leaving the Subclipse guys having their own external development area (Tigris.org), but still having Subclipse bundled with Eclipse so I don't have to download it with every install. (not a huge pain, but still) :) Just ask Subclipse team to provide standalone ZIP which can be downloaded using "wget" and extracted into dropins. Then use little script to download and install or replace Subclipse. See for example how we build our products http://downloads.instantiations.com/D2RCP/continuous/latest/ So, you always know URL for latest version and don't have to fight with Update Manager. Just curious, will we ever see a Subversion client get embedded as part of 'core' Eclipse? At this point it seems ridiculous that we all have to load one of the SVN plugins to get access to arguably the most popular open source VCS. What is even more fascinating is that in the time this bug has been open, Subversion was 'eclipsed' by the distributed version control systems, notably mercurial and git. It might come to pass that this will be closed with WONTFIX and not too many people will raise a fuss. Florin - good point. But as long as there are control freaks (such as myself) and until the DVCS tooling matures there will still be people that want to use SVN. I am just having a hard time understanding why we can't resolve the issues and get SVN support baked into Eclipse. (In reply to comment #115) > But as long as there are control freaks (such as myself) Control freaks use DVCS too ... > ... and until the DVCS > tooling matures there will still be people that want to use SVN. I am just > having a hard time understanding why we can't resolve the issues and get SVN > support baked into Eclipse. The issue is not a technical one, it's a legal one. The libraries that the Java SVN binding use are still not Eclipse compatible. Even with Apache hosting Subversion as a top-level project, the issue has not been resolved; the licenses are still incompatible. So the understanding is this: until you personally write a SVN-Java layer that is compatible with the EPL (or AL), you are personally holding up the adoption of SVN. Please attach the required implementation to this bug and then the blocker can be resolved. Use Subclipse with JavaHL (native bindings) and be done with it -- they're EPL and APL, respectively. (In reply to comment #116) > So the understanding is this: until you personally write a SVN-Java layer that > is compatible with the EPL (or AL), you are personally holding up the adoption > of SVN. Please attach the required implementation to this bug and then the > blocker can be resolved. Right now, I see two other solutions: 1. We get an official site for non-EPL plugins where stuff like that is gathered. One update site, a few seconds to set it up once, then the installation works like always. It would be great if Eclipse would already include the update site by default but if that's a legal problem, so what. 2. We could ask the SVN people to dual license their code. It's not hard to do but rarely done. #1 would work, it wouldn't be a lot of trouble and solve all problems but the "how do I make this work on some esoteric platform". I think the solution here is a heterogeneous build farm (like the one Eclipse uses for headless builds). Projects submit source code to the farm, it gets compiled for all platforms and then uploaded to the update site. #2 would be most simple but I'm not sure all the code can be dual licensed in such a way to pass the IP process. Lastly, I've seen a site once which offered an ARM simulator written in Java. The code was designed in such a way that it could execute C code that was compiled with GCC for the ARM architecture. This way, you could execute assembler code. Unfortunately, I couldn't find the site again. But basically, the idea to modify the C code in such a way that it runs against a simple VM which implements the OS calls the code needs. This VM would be implemented in Java. Then, we would just need to compile the C source code once to have it on all platforms. (In reply to comment #117) > Use Subclipse with JavaHL (native bindings) and be done with it -- they're EPL > and APL, respectively. I like that option only if the native bindings will be built for all platforms for which Eclipse supports SWT. (In reply to comment #118) > Right now, I see two other solutions: > > 1. We get an official site for non-EPL plugins where stuff like that is > gathered. One update site, a few seconds to set it up once, then the > installation works like always. It would be great if Eclipse would already > include the update site by default but if that's a legal problem, so what. Are you referring to the site mentioned at: http://www.eclipse.org/subversive/downloads.php "Important: Subversive installation includes Subversive plug-in and Subversive SVN Connectors plug-in. In order to start work with Subversive you should install both of them. Subversive SVN Connectors are distributed from an external location due to licensing requirements. Visit external Polarion site to get Subversive SVN Connectors" I'm not sure why this doesn't meet your definition of #1 already, but the update site to the external location can't be included by default in the Eclipse platform for the licensing reasons. > 2. We could ask the SVN people to dual license their code. It's not hard to do > but rarely done. It has been asked, it hasn't happened. See here why Subclipse isn't distributed with the binaries: http://subclipse.tigris.org/wiki/JavaHL#head-1c75c22d4d8e9c3cd16868bdd3d6157637589ef0 The Java-only solution is incompatibly licensed with EPL and is described here: http://svnkit.com/licensing.html Alex Isn't this bug outdated, now that Subversive has become a fully graduated Eclipse project? (In reply to comment #121) > Isn't this bug outdated, now that Subversive has become a fully graduated > Eclipse project? Subversive graduated from incubation a year ago and we released Subversive 1.1 recently. The project is mature, but there are other problems that prevent the project distribution as a part of Eclipse. One of these problems is incompatible license of SVN connectors that was identified by Eclipse legal team. SVNKit and JavaHL have licenses incompatible with Eclipse requirements. SVNKit has a proprietary license type, JavaHL before version 1.8 had a networking component that had incomatible license, that's why connectors can't be distributed from eclipse.org. In the SVN 1.8 this component was replaced by another component with compatible license. It means that some of blocking points are now removed, but we will need to have another round of legal review to be sure that JavaHL 1.8 is compatible with Eclipse legal requirements. So far Subversive is a part of Simultaneous Release, so it's easy to install it from the Simultaneous Release update site - now it's just a one-click process, so probably SVN client inclusion into standard distribution isn't such critical as it was time ago. This bugs has moved to: https://gitlab.eclipse.org/eclipse/subversive/subversive/-/issues/1 |