Community
Participate
Working Groups
The Foundation should offer a Subversion repository to their projects. It should be offered in parallel. Existing projects should not be forced to migrate. However, a migration guide should also be worked out in coordination with bug 71735. At a later point in time CVS should be deprecated.
*** This bug has been marked as a duplicate of 71735 ***
Removing the duplicate. Bug 71735 is for the Eclipse project to support/move to SVN, whereas this bug is for the Foundation to provide the actual subversion repositories. D.
Thanks :) Do you still have the issue with missing Subversion binaries for your OS?
For now, yes, but a new version of SLES is due out in June, hopefully it will have them. Otherwise, we'll look into compiling from source. grrr ;) D.
+1
SLES 10 does not have a subversion server in the OS. However, we'll with run a binary from here, or build our own: http://ftp.suse.com/pub/projects/apache/subversion/ Matt has sandboxed this and it's in the works. Matt is targetting SVN availability to projects for August 2006. D.
Reassigning to webmaster.
Subversion has been installed on build.eclipse.org for testing purposes. If you would like to test subversion, please send in a request for a repository to be created on build. Please note that these repositories will be for testing only and will not be moved into production when we are satisfied that subversion is ready for production use. You will be able to use your current committer user ids and passwords to access subversion on build. -M.
We're planning on rolling out SVN repositories on dev.eclipse.org in Q4. It should be noted that until the large majority of projects have switched over, we have no plans on making CVS deprecated. Projects will be free to move from CVS to SVN as they wish, if they wish to do so. We'll leave it up to the project leads to pick the right tool for the job. D.
Matt is assigned to this. Target for Q4.
How are things progressing with this? I'm volunteering to be one of the brave frontiers trying a first beta :-)
Svn is now installed and ready for use. There is both anonymous access and ssh access for committers. Committers connecting via ssh should use the basepath of: /svnroot/toplevelprojectname/repository . Anonymous users can use the basepath of: /toplevelproject/repository . This difference is caused by the root path setting for anonymous svn which restricts anonymous users to the /svnroot directory. We will help projects migrate that want to move from cvs to subversion, but please note the file history will not be transfered. Also projects are free to chose either subverion or cvs for their source but not both. At this time there is no auto-checkout mechanism for subverion, so project websites will remain in cvs. ViewVC has replaced ViewCVS on dev.eclipse.org, and now supports the browsing of subversion repositories. This is available at http://dev.eclipse.org/viewsvn . -M.
(In reply to comment #12) > We will help projects migrate that want to move from cvs to subversion, but > please note the file history will not be transfered. Also projects are free to > chose either subverion or cvs for their source but not both. Why not use the cvs2svn tool to let people migrate history? It generally works very well, even groups/converts CVS commits into atomic SVN revisions. Mark
> Why not use the cvs2svn tool to let people migrate history? It generally works > very well, even groups/converts CVS commits into atomic SVN revisions. That's because we're SVN idiots (well, I am anyway) and we're learning all this as we go along. We promise to try cvs2svn when migrating CVS repositories to SVN. Thanks for the tip. Matt, can you sandbox cvs2svn and give it a try?
I'd be happy to offer you some off line assistance if you would like it. I have a lot of experience supporting Subversion commercially (although not specifically on SUSE). I was also going to ask whether you considered using http and https for serving instead of SSH? The latter does offer the user a little better performance but it is also a little more difficult for the user to setup. At a minimum, I'd recommend you do what a lot of other services do and that is use http:// for anonymous access and svn+ssh:// for committers. Part of this request is selfish. I am responsible for the Subclipse plug-in and it works a lot easier with https than SSH. The latter works fine but the configuration for the user is a lot less automatic. Finally, it seems like you might be considering giving each project its own repository? For example SWT in one repository, JFace in another? If you are, then you might want to reconsider as it would make tagging more difficult. Apache has every project in a single repository. I'd recommend that approach, or at least one per top-level project, such as Platform, Tools, Technology etc...
I agree with comment 15. I think it's also unusual for communities using Subversion to remember two locations instead of one. The common way of providing public Subversion access is boxing it through Apache using Apache for authentication and a file for read/write permissions. HTTP will work but HTTPS is required for committer (i.e. authenticated) access. The repositories should be accessible using https://dev.eclipse.org/svn/toplevel/project.
Comment 16 almost sounds like a requirement that should have been made back in August. See comment 8 where we had sandboxed svn yet no one appears to have tested it nor offered any insight as to how we "should" set it up, or how the community would prefer to access it. Let's maintain score... Adjust as appropriate if my assumptions are incorrect. https vs. ssh I read http://svnbook.red-bean.com/en/1.0/ch06.html especially the table towards the bottom of the page. It claims svn over ssh is faster than over https. "speed" is often a delicate issue with committers; ie, comments are made when there is not enough of it, hence our choice to not host over Apache. http: 0 svnserve: 1 If I understand correctly, to use svn over Apache we'd have to compile and load an Apache module - mod_dav_svn, besides using mod_dav, which is shipped with our OS. I hate dav - the idea that Apache is writing to my file system makes me sick to my stomach. Also, we don't run self-compiled Apache modules. This would be a first for eclipse.org. http: 0 svnserve: 2 snvserve vs. https setup and maintenance. svnserve seems much simpler by design, instead of relying on Apache and Apache modules/config file changes/HUPping Apache etc. http: 0 svnserve: 3 Community: appears using svn through http/https is easier for the end user instead of svn over ssh http: 1 svnserve: 3 Per-project access levels As suggested in comment 15, we'd likely want to set up one repo for each top-level project, as we do currently with CVS. However, svn needs to respect who can commit to specific projects, and oftentimes, allow fine-grained access control within the project itself. It's not clear to me which is easier/better for this task. Mark, do you have any ideas? File contention/load balancing/locking Our servers are load balanced, so https connections can bounce from one physical server to another. This is true of ssh also; however, currently with cvs, all commits are batched in the same ssh connection. It's unclear to me whether svn over https is suitable for a clustered Apache setup that shares a common storage backend. Mark, what do you think? Security If https is used for commits, does this mean all the files need to belong to, and be writable by Apache? If so, http: 1 svnserve: 4 Reopening, as it seems we're not ready to host SVN repositories yet...
(In reply to comment #17) > Let's maintain score... Adjust as appropriate if my assumptions are incorrect. > > https vs. ssh > I read http://svnbook.red-bean.com/en/1.0/ch06.html especially the table > towards the bottom of the page. It claims svn over ssh is faster than over > https. "speed" is often a delicate issue with committers; ie, comments are made > when there is not enough of it, hence our choice to not host over Apache. You should read the latest versions of the book. http://svnbook.red-bean.com/nightly/en/index.html The 1.0 version is a bit old now. But this is still true. http is slower because it is stateless and more verbose. > If I understand correctly, to use svn over Apache we'd have to compile and load > an Apache module - mod_dav_svn, besides using mod_dav, which is shipped with > our OS. I hate dav - the idea that Apache is writing to my file system makes me > sick to my stomach. Also, we don't run self-compiled Apache modules. This would > be a first for eclipse.org. dav is not writing to your file system. mod_dav is like a router. You still need the provider like davfs which writes to a file system. In this case, the provider is mod_dav_svn which is just Subversion and reads/write to the repository. I do not see why compiling modules is an issue, but there should be pre-built binaries available regardless. > snvserve vs. https setup and maintenance. > svnserve seems much simpler by design, instead of relying on Apache and Apache > modules/config file changes/HUPping Apache etc. If you were starting from scratch, I'd say Apache is easier. But since you already have the SSH infrastructure established, then svnserve is probably easier. The Apache maintenance is pretty minimal. A few lines in the conf file that you never need to touch again and you are done. > Community: appears using svn through http/https is easier for the end user > instead of svn over ssh Why not do what I suggested? Setup Apache for anonymous access via http and use svn+ssh for commit access? This is what many other hosting sites do. With Subversion 1.4 you could even use svnsync to maintain a mirror repository that was being served via http for anonymous access. Probably not something that is needed right now, but that is another option. > Per-project access levels > > As suggested in comment 15, we'd likely want to set up one repo for each > top-level project, as we do currently with CVS. However, svn needs to respect > who can commit to specific projects, and oftentimes, allow fine-grained access > control within the project itself. It's not clear to me which is easier/better > for this task. Mark, do you have any ideas? As of Subversion 1.4, the capabilities are now the same. Prior to 1.4, only Apache offered fine-grained access control. Now the same access control can apply to svnserve. The same access control file is used by both access methods. > File contention/load balancing/locking > > Our servers are load balanced, so https connections can bounce from one > physical server to another. This is true of ssh also; however, currently with > cvs, all commits are batched in the same ssh connection. It's unclear to me > whether svn over https is suitable for a clustered Apache setup that shares a > common storage backend. Mark, what do you think? I do not have any experience with this one. I might be able to get you in touch with someone from CollabNet that could answer. > Security > > If https is used for commits, does this mean all the files need to belong to, > and be writable by Apache? I think that this is true but can be controlled via the conf file. If you serve anonymous repository via http, Apache will need to be able to read the files.
Why not use cvs2svn <http://cvs2svn.tigris.org/> to preserve project VC history? It's extremely reliable, and produces a Subversion dump file from a CVS module which can be loaded into the project's new Subversion repository.
svnserve vs apache I can't say that I've had any issues with using the subclipse plugin via ssh as it behaves just like the cvs module does. Given that most committers are going to be accessing their repository from within Eclipse is there any advantage to using https? Keep in mind that as Mark pointed out we have a functional ssh infrastructure that works with either subclipse or the commandline svn tools. As a rule we try and keep hand compiled software to a minimum on the cluster just to contain the number of things that need to be redone on a rebuild/install or watched for security/bug fixes (http://wiki.eclipse.org/index.php/Webmaster_FAQ#You.27re_running_Something-1.0.2.__Why_don.27t_you_use_SomeOtherThing-3.4.5_instead.3F_It.27s_way_cooler. ). Multiple projects in one repository The issue here as I see it is that while we could put multiple projects(GMF,EMFT and UML for example) inside one repository (say modeling) the global nature of revision counts in subversion causes a problem, since the GMF folks could commit rev 1, and then not check in anything for a week and end up at revision 499 since the other projects were really busy. While that may not be much of an issue for the folks that want subversion it does/could make it difficult for other people. Access control This seems to work quite well on a per repository basis with Subversion 1.4 over ssh. And I've pulled a copy of cvs2svn and I'll do some test imports, but it looks like that will solve the cvs history migration problem. -M.
(In reply to comment #20) > I can't say that I've had any issues with using the subclipse plugin via ssh > as it behaves just like the cvs module does. The main issue is that we do not control the SSH config. If you are using the native JavaHL option, then it relies on how you configured the SVN command line to use SSH. If you are an experienced SSH user, running a key-agent and the like, then this is all perfect. For a newbie, it is tough. If you use the pure Java option, SVNKit, then it uses a Java SSH library and prompts you for information. This is easier, but doesn't use your SSH client and setup if you wanted it to. > Given that most committers are > going to be accessing their repository from within Eclipse is there any > advantage to using https? Keep in mind that as Mark pointed out we have a > functional ssh infrastructure that works with either subclipse or the > commandline svn tools. Just that https is a no-issue for the user to use. Type in the URL, accept the certificate, and you are done. > As a rule we try and keep hand compiled software to a minimum on the cluster > just to contain the number of things that need to be redone on a > rebuild/install or watched for security/bug fixes I thought SUSE had up to date SVN modules and would include mod_dav_svn, so I do not see why you would need to compile anyway. >(http://wiki.eclipse.org/index.php/Webmaster_FAQ#You.27re_running_Something-1.0.2.__Why_don.27t_you_use_SomeOtherThing-3.4.5_instead.3F_It.27s_way_cooler. I do not think this is the same scenario, especially if binaries are not available. I'd suggest you use SVN 1.4.2 (the latest), but at least use 1.3.2. > Multiple projects in one repository > > The issue here as I see it is that while we could put multiple > projects(GMF,EMFT and UML for example) inside one repository (say modeling) the > global nature of revision counts in subversion causes a problem, since the GMF > folks could commit rev 1, and then not check in anything for a week and end up > at revision 499 since the other projects were really busy. That is a complete non-issue. Will some people bitch? Sure. But it is just silly. The revision is an SVN mechanism, there is no reason for the user to attach significance to it. The Apache projects seem to manage, and they have every Apache project in one repos. They do not even separate out httpd from Jakarta as an example. > Access control > > This seems to work quite well on a per repository basis with Subversion 1.4 > over ssh. As of 1.4, svnserve has the same feature as mod_dav_svn, which means you can control right down to the individual folder within the repository. That brings up another issue. Have you looked into hook scripts? It would be nice to have the mailer.py script activated so that commit emails were sent. This is a feature I really like in general.
I can confirm that one our our early mistakes was creating separate repos for the numerous projects we had. At 1st the thought was to mirror what was setup in ClearCase (a truly petaQ of a SCM system) into Subversion and while it is definitely doable there is definitely more work when tagging, branching, etc. Now all new projects go into a single repo for the equivalent of an Eclipse top level project. This had made the last couple years of maintenance trivial. I also agree with setting up Apache to front the access to the repositories. This has the benefits of being able to use all the authentication mechanisms that apache makes possible (currently we authenticate via LDAP into Active Directory).
Oh, forgot to mention that the whole svn version # moving because other projects have done checkins was more of a communication problem than anything. We just needed to explain how subversion has a repository version # for every action and not a version # for files, folders, etc. Seriously, in cvs if you work on a class and the version # is 2.3 when you go for a week of vacation and the version is now 4.1 when you come back what does that mean? It likely means there were some checkins and that marketing it playing fast and loose with version #'s again.
So if this were installed does that mean that most of those committers who use only SVN would no longer need SSH accounts, only LDAP auth privileges via Apache? -Karl
(In reply to comment #24) > So if this were installed does that mean that most of those committers who use > only SVN would no longer need SSH accounts, only LDAP auth privileges via > Apache? > > -Karl > If I understand you correctly, then that would be correct. None of the 60+ devs have accounts on the svn repo machine nor it's backup. The just need to be in LDAP and with about 10 lines of ldap configuration you're good to go.
I think it's worth reiterating that we are providing Subversion repository support for those eclipse.org projects who wish to use it. This does not mean that all the Eclipse projects will be migrated to SVN, so don't expect to be pulling Eclipse Platform source code from SVN anytime soon (hey, that's bug 71735!). It's optional, and we will let the projects choose which version control tool is best adapted to their needs. If they don't like the fact that other projects' commits can impact their revision numbers, then they can choose to use a CVS repository. > I thought SUSE had up to date SVN modules and would include mod_dav_svn, so I > do not see why you would need to compile anyway. Curiously, SuSE Linux Entreprise Server 10 on ia64 does not have any out-of-the-box subversion support. The closest we could get is this empty directory, and for SLES9: http://ftp.suse.com/pub/projects/apache/subversion/sles9-ia64/ We built our svn RPM for ia64 from source, but we don't enjoy straying from the Entreprise OS that we have support for. Not having to compile additional Apache modules is a big bonus for us for reasons I explained in bug 71735 - one of them being that we don't have the human resources to start applying patches from source when there are security updates. However, I will discuss this with Matt and Karl to see how they feel about maintaining http[s] support for Subversion, versus the dead-simple and quite functional SVN over SSH and svnserve. We have the ability to effectively "disable" SSH shell access anyway for any of our committers, so SVN over https still isn't buying us anything that SVN over SSH isn't providing. > That is a complete non-issue. Will some people bitch? Sure. But it is just > silly. I find this statement a bit narrow, although I do agree that those projects who will choose (and I do say "choose") to use SVN are probably not worried about the version/revision number. For those who want to migrate from CVS to SVN, they will need to be aware of that. > The revision is an SVN mechanism, there is no reason for the user to > attach significance to it. We will do our best to pass this on to the project teams that choose SVN. > That brings up another issue. Have you looked into hook scripts? It would be > nice to have the mailer.py script activated so that commit emails were sent. > This is a feature I really like in general. We have this for CVS, and will likely implement them for those projects who need SVN commit notifications. We've also decided to host one SVN repo per Eclipse top-level project, instead of one repo per project. Thanks for the advice, this setup should work well for us.
(In reply to comment #26) > > I thought SUSE had up to date SVN modules and would include mod_dav_svn, so I > > do not see why you would need to compile anyway. > > Curiously, SuSE Linux Entreprise Server 10 on ia64 does not have any > out-of-the-box subversion support. The closest we could get is this empty > directory, and for SLES9: I doubt this will be of help, but OpenSUSE has up to date RPM's available: http://download.opensuse.org/distribution/10.2/repo/oss/suse/x86_64/ There are similar folders for 10.0 and 10.1 > We built our svn RPM for ia64 from source, but we don't enjoy straying from the > Entreprise OS that we have support for. Not having to compile additional Apache > modules is a big bonus for us for reasons I explained in bug 71735 - one of > them being that we don't have the human resources to start applying patches > from source when there are security updates. As long as you are not customizing the source, I'd assume you would just rebuild from the release tarball. If there was a Subversion security update, it would come in a new release, like 1.4.3. > > That is a complete non-issue. Will some people bitch? Sure. But it is just > > silly. > > I find this statement a bit narrow, although I do agree that those projects who > will choose (and I do say "choose") to use SVN are probably not worried about > the version/revision number. For those who want to migrate from CVS to SVN, > they will need to be aware of that. The point is just that anyone that is attaching this level of significance to the revision number just doesn't understand Subversion. They will have to get over it. I do not see people attach significance to CVS revisions. With both Subversion and CVS you create tags to attach significance to a set of code. > We have this for CVS, and will likely implement them for those projects who > need SVN commit notifications. > > We've also decided to host one SVN repo per Eclipse top-level project, instead > of one repo per project. Thanks for the advice, this setup should work well > for us. Sounds good. FWIW, even though I prefer Apache and https, I think that for Eclipse, given your existing SSH infrastructure, the svn+ssh option makes the most sense for commit access. I'd just suggest using http for anonymous access for ease of use to the user. Mark
Cool. So I'll close this as fixed. Here's a summary: - we'll provide SVN over SSH for committers, and SVN over svnserve for anonymous - we won't provide SVN over http[s] initialy because there is no support for our OS/architecture and we cowardly don't want to mess with our Apache cluster - we'll investigate using http[s] at a later date if SuSE provide ia64 RPMS - we'll create one SVN repo for each top-level project when one project requests SVN support. Subsequent projects in the same top-level will be added to SVN as projects, not independent repositories - we'll help projects migrate to SVN by using cvs2svn - I'll post an announcement to all our committers, advising that SVN repositories are available. Thanks to everyone for your feedback, and for helping us get this set up (somewhat) correctly.
That all sounds good to me. I'd also mention your plans for hook scripts as people will be interested to know what hooks are going to be available.
(In reply to comment #27) > [...] With both > Subversion and CVS you create tags to attach significance to a set of code. This reminds me of something, do we need a reliable protection for committing stuff on tags? And for the rest, I will learn to use svn+ssh with Subclipse/TortoiseSVN. ;)
Is svnsync supported? Google code and Sourceforge support svnsync now so that would make it easier to incubate something off site and then move it to eclipse.org after a project proposal was accepted - even keeping it in both places for a while would be possible. Also, Is there a reason not to just have one repository that everybody shares? Projects get reorganized from time to time, and SVN has good support for that within a single repository, but I think if a move was between repositories it would be unnecessarily complicated. If some technical reason like load-balancing arises that makes it necessary to split repositories in the future that's always an option, but I don't think you should start off that way. You may never have to split, you don't know.
I think svnsync just requires that they are running 1.4 on the server. They should be doing this anyway for the access control features of 1.4 which they said they needed. svnsync can currently only mirror an entire repository. That would be one argument AGAINST a single repository. I have used svk for mirroring for years and that can do subsets of the repository and does not require anything but read access to the remote repository. Another consideration to factor in is that there is no way to permanently delete something from an SVN repository. So if someone commits something that they should not have, it can be deleted from the current view, but someone can still access it if they know the revision it exists. The only way to fix this is to dump the repository, edit the dumpfile and then reload. That might be another argument against a single repository -- should this issue ever arise. I think the Apache people have managed to deal with this OK. I think the main argument for one repository would be if projects move within the Eclipse structure during their lifecycle. For example, suppose that something like Mylar, or elements of it, graduated to the Platform SDK. The code could simply be moved, with all history included, if there was a single repository. If they are in different repositories, it is virtually impossible to do something like that.
(In reply to comment #31) > Also, Is there a reason not to just have one repository that everybody shares? I feel this comment does require more thought. Are we creating one repo per top-level simply to mimic CVS? Back in the day, Eclipse's CVS could have been set up with one single repository too, one directory per project. Now's the time to build this right, because once a bunch of projects start using SVN, making these types of decisions isn't as easy. One repo vs. many: Administration: not much difference from what I can tell. No clear winner. Moving projects: +1 for One repo. Actually, moving projects is a hard requirement for us, and if they all share the same namespace, then there's nothing to move. I think this is why we originally thought of having one repo/project, but one single repo makes even more sense. How about SVN database corruption/restore? How about erasing files from SVN because they were committed inadvertently? From what I can tell, this will be a CVS-only 'feature'. I doubt we're going to dump/filter a repository until SVN has some built-in mechanism to erase stuff.
Repository problems is rare. I assume you plan to use the "fsfs" repository format which has been the default since 1.3? There are no real reports of problems with those repositories. The problems with BDB repositories is supposed to be resolved with 1.4. and BDB 4.4. That was never corruption, but the repositories could be off-line while you fixed problems. In general I am also in favor of a single repository. These are the problems I think you'd want to be aware of with that approach: 1) Bigger repository means longer dump/load time, should you need to do that. Subversion is not likely to require you to run a dump/load until the 2.0 release , which is barely in the planning stages, but it has not been uncommon for a dump/load to be required to take advantage of some internal improvements. 1.3 introduced a new delta algorithm that made certain operations like annotate run faster. 1.4 introduced a new feature to use zlib compression within the repository. This made the repository smaller, which reduced the read times and sped up overall performance. 2) A single repository will place a greater need for the "authz" feature of Subversion, which may or may not be a burden for you to maintain. If you want to lock down committers to specific areas of the repository it will require editing this file whenever there are any committer changes. This could probably be automated somewhat and it is hard to say if having a single repository even makes this more difficult to do.
(In reply to comment #34) > 2) A single repository will place a greater need for the "authz" feature of > Subversion, which may or may not be a burden for you to maintain. If you want > to lock down committers to specific areas of the repository it will require > editing this file whenever there are any committer changes. This could > probably be automated somewhat and it is hard to say if having a single > repository even makes this more difficult to do. svn+ssh has the nice advantage that the process gets executed as the authenticated user. Thus, I'm wondering if the auth file is being used or if you think about handling it the same way as with CVS, i.e. use file permissions? I think in the latter case you need the one repository for each project approach because a user committing to a repository needs file write permission to the whole repository files. (See the gray box on the bottom of http://svnbook.red-bean.com/en/1.0/ch06s05.html.)
We realized that everyone using the repository needed write access to it, so we were intending on using the authz file. This will allow us to isolate SVN group access from LDAP/CVS group access. This method also keeps the door open should we need/want to switch to https instead of svn+ssh
> - we won't provide SVN over http[s] initialy because there is no support for > our OS/architecture and we cowardly don't want to mess with our Apache cluster > > - we'll investigate using http[s] at a later date if SuSE provide ia64 RPMS I'd really, really, really like it if there were HTTP support for accessing files anonymously. We live behind corporate firewalls at work, and whilst we can see stuff over HTTP, anything over any other port (including CVS) is just plain impossible. Accessing up-to-date code (e.g. for patching, fixing) generally becomes a case of download a version at home, tarball it up, and e-mail it into work to do some bits, and then the reverse out again afterwards. Having HTTP access would instantly open up (simple) access, and the same would be true of any other organisation using firewalls to block non-standard ports (i.e. pretty much everything except port 80 :-) If it's not going to be addressed here'n'now, then I suggest opening up a separate enhancement request to track it individually. Then I can vote for it and encourage others to do so too :-) In fact, one of my personal hopes of using SVN would have been that access would have been possible over HTTP ... but instead of needing access via port 2401, we now need access via port 3690 instead :-(
I'm really, really, really losing sympathy for the poor corporate users whose firewalls don't allow them to access our anonymous content. I mean, if your corporate firewall prevents you from accessing our wide-open-come-and-get-it anonymous SubVersion, then there must be a reason for that. By channeling everything through port 80 we're perhaps allowing you to bypass the policies of corporate IT. Who knows. Why not open a bug against your Corporate IT, and get other Corporate users to vote +1 to have the firewall opened? I'll vote +1 on it too if you send me the link. Remember, as more and more content is shoveled through port 80 to bypass corporate firewalls, the effectiveness of the policy is dimished, forcing IT to get tougher by, say, implementing http proxies and filters. Aren't we all looking forward to that!
Denis, I know you work for an open organisation, but your attitude is hardly one of your strong points :-) Many internal networks are on completely different IP subnets to the outside world. There is usually no IP connectivity between those internal networks and the outside world, on any port. In fact, the only way that you can get out is via the HTTP proxy to something that speaks HTTP, like an HTTP server. There are also some ISPs that do port filtering in general. But, as usual, your response is one of RESOLVED CANTBEARSED, much like adding a DNS entry was way too much like work for bug 157502 It's a wonder that anything gets done.
Alex, actually these days most companies use stateful inspection firewalls with NAT (sometimes tcp redirected or NATed through a web cache) to handle the private/public IP problem. True, those with the strictest security requirements still require application gateways but that is becoming a rarer case. SSH is already a working solution for the vast majority of our committers. That being said, in any production environment there is a cost/benefit analysis which has to happen. In this case, doing as you ask will require the very small team here to take on a relative large burden vs the perceived benefit. Sure it would help some people. But since we don't have native packages for IA64 for any of this stuff it puts us in compile, build, realease mode for updates for another application (httpd modules). Keep in mind there are _3_ people running this whole infrastructure. And one of us is new to the team. :) Have you tried requesting this through your own company processes?
(In reply to comment #39) > Denis, I know you work for an open organisation, but your attitude is hardly > one of your strong points :-) You took it the wrong way. My rant is that against corporate networks. While I do sympathize with folks who cannot get to our services, I think it's unfortunate that a network can be secured to the point of being crippled and non-functional, where everything needs to come through port 80 leaving everyone else no other option but to shape their services accordingly. Regardless, anonymous SVN over http would likely be a good thing for most, and we recognized that in comment 28. Opening a bug for http support would allow us to track the issue separately, although we will investigate it when it's possible for us, bug or no bug.
Karl; even IBM doesn't allow end IP connections to the outside world on any port. In fact, go to any of the IBM training courses on network security, and they'll use terms like 'DMZ' to completely firewall off external access to the webservers, and then again to those internally. Heck, even I've got two firewalls between me and the internet, and this is at home. There are servers -- like SOCKS services, for example, which IBM has been known to use from time to time -- that are situated in the DMZ to allow certain ports to the outside world. Not all companies use (or provide) this. In fact, the more secure a company is, the less likely they are to have access to the outside world other than through the proxies, and even then, those are still potentially restricted. It's not actually a NAT problem. Denis; corporate networks are a fact of life, in any large company. There are benefits to restricting what can (and can't) get in and out of a network. For one thing, if a virus were to get on board our systems at work, we'd have a potentially serious problem on our hands and the chance of serious data loss. If something were to be infected, the virus couldn't "phone home" with the data, or to provide mechanisms to remotely control it. I don't see these as restrictions or a loss of functionality; HTTP access (and no, not just general port 80 access, but going through HTTP proxies/filters) is sufficient for almost all kinds of access. For example, if I wanted to show you what I'm doing on the Pack200 stuff for harmony, you can just point http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/archive/src/main/java/org/apache/harmony/archive/internal/pack200/Segment.java in your browser to see the code. You don't need anything on the client; it's just web-based access, and it works. Or, if you've got a Mac, you can do Command+K from the finder, and put in http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/archive/src/main/java/org/apache/harmony/archive/internal/pack200/ as the URL, and it will mount it as a directory. You can also do the same with Windows, by adding a new network location (My Network Places -> Add New Network Location or something like that), and it will show up as a network share. All of these are possible, because web access is a de-facto standard, not just a network port. (Some of the WebDAV stuff will only work if there's a WebDAV compatible proxy; but then again, that only makes sense if you're not using anonymous/read-only access anyway.) Raised bug 168282 as an enhancement.
(In reply to comment #42) > For example, if I wanted to show you > what I'm doing on the Pack200 stuff for harmony, you can just point > > http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/archive/src/main/java/org/apache/harmony/archive/internal/pack200/Segment.java Oh, you mean like this: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.core.boot/src/org/eclipse/core/internal/boot/BundleStats.java?revision=1.5 That's ViewVC, which is set up for both CVS and SVN. There aren't any SVN repositories yet, but as we create them on the server they will appear in the repo selection here: http://dev.eclipse.org/viewsvn/index.cgi/ I know this likely doesn't qualify as SVN over http, but it does allow you to pull files and see diffs over http while we wait for 168282.
FYI the availability of SVN over HTTP is more than just seeing it via viewvc. For one thing, you can't check out the HEAD of a project using viewvc. Secondly, viewvc is pretty slow and it's quite difficult to get even a handful of files out without having some serious patience :-) It's also nice that you can mount drives over WebDAV, which you can't do over viewvc :-) Alex.
(In reply to comment #44) > FYI the availability of SVN over HTTP is more than just seeing it via viewvc. I acknowledged this in comment 43... ViewVC is better than nothing while we wait for bug 168282.
(In reply to comment #42) > Karl; even IBM doesn't allow end IP connections to the outside world on any > port. In fact, go to any of the IBM training courses on network security, and > they'll use terms like 'DMZ' to completely firewall off external access to the > webservers, and then again to those internally. Heck, even I've got two > firewalls between me and the internet, and this is at home. > > There are servers -- like SOCKS services, for example, which IBM has been known > to use from time to time -- that are situated in the DMZ to allow certain ports > to the outside world. Not all companies use (or provide) this. In fact, the > more secure a company is, the less likely they are to have access to the > outside world other than through the proxies, and even then, those are still > potentially restricted. It's not actually a NAT problem. > Alex, I'm not sure debating the technical details of this is of much use so I'll just let it drop. I would just say that my experience at a number of companies as a consultant and employee has differed from yours. I will move my remaining comments about webdav to the new bug.
Update for mod_dav_svn on SLES 10.x: For SLES 10, Subversion is in the SDK <http://developer.novell.com/wiki/index.php/SLES_SDK#Intel_Itanium_Processor_Family_.28ia64.29_platform>. mod_dav_svn is included in its subversion-server package. If a newer Subversion package is required, SuSE's Peter Poeml can recompile newer packages for Eclipse. Alternately, for x86_64/i386 you can use packages from the Build Service <http://build.opensuse.org/>. Packages for Subversion can be found at <http://software.opensuse.org/download/Subversion/>.
