SVN for clients

[Jaggi]

Just thinking it might be a good idea to have a svn for clients so that we can update our forum via svn. Doesn't need to be a live area as i've seen topics before saying this wouldn't be very possible but i use svn with alot of my softwares and think its a nice and easy way to update them with little effort. Would enable us to download bug fixes and security updates instantly too..

[Lindsey_]

1

[Sire]

Yes, please make this possible! +1
svn update

[Digi]

Unfortunately I'd say this is unlikely. The PHP SVN functions haven't seen an update in a few years, while even the svn client has seen one. Not only that, but the limited functionality that actually exists is considered "experimental".
http://us.php.net/svn

EDIT: I lied. It appears that jsut recently (this month actually) an update was done to the pecl package. So the functionality that is available is at least up to date with SVN core now. However, the extension is still considered experimental, which is never good for a real project :) (the fact that a PECL extension requires a non-compiled library like PEAR turns me off significantly)

http://pecl.php.net/package/svn

[bfarber]

Err - Digi... they were asking for access to our SVN repo (or a separate repo with the current IPB files in it). Not any sort of PHP SVN functionality. :unsure:

[Digi]

lulz, sorry for misreading then :)

[FrenchieMac]

Big fan of the idea!

[Rikki]

The problem would be restricting it to clients. We would have to have some system to manage access, and then how do we detect someone sharing their login? SVN access works well for open source/freeware projects, but I'm not sure it would work so well for commercial projects where you need to ensure someone is eligible :)

[Guest]

I think this is a cool idea, but i'm not sure how easy it would be to implement the login part of things. I don't think SVN has any sort of support for bridging to database-based login systems, and I don't think IPS would like to export every customer's login details to the SVN login config ini file. ;)

The problem would be restricting it to clients. We would have to have some system to manage access, and then how do we detect someone sharing their login? SVN access works well for open source/freeware projects, but I'm not sure it would work so well for commercial projects where you need to ensure someone is eligible :)

Surely you're in the same position around detecting login sharing for the customer area though?

[Rikki]

I think this is a cool idea, but i'm not sure how easy it would be to implement the login part of things. I don't think SVN has any sort of support for bridging to database-based login systems, and I don't think IPS would like to export every customer's login details to the SVN login config ini file. ;)

Surely you're in the same position around detecting login sharing for the customer area though?

People don't tend to share their login information to the client area because it also contains their billing information, and the ability to purchase other products directly. The safeguard for that is the risk of information being abused if you share that login.

[Guest]

People don't tend to share their login information to the client area because it also contains their billing information, and the ability to purchase other products directly. The safeguard for that is the risk of information being abused if you share that login.

Ah, good point. :)

[Jaggi]

Yea i agree that the login issue could be a problem however there are alot of sites out there that have a unique password/login features for users and some of them have much more users than ips so it is doable. Although writing a config file wouldn't be that bad which could update daily or you could even go futher where you make it a feature for clients to set in their client area so when they choose "enable svn access" then it turns it on for you so then ips only have to worry about ppl who turn it on :D.

As for people using other peoples logins well thats just nit picking because you have that problem now.

[Mat Barrie]

Jaggi, read what Rikki said. It details exactly why they don't have that problem now. Then again, should any access like is requested in this thread be granted they could use your client centre login which would extend the same protection to it.

Then again though, think about it from their perspective - is there any value to be added by providing access to the latest "golden syrup" (AKA may not work, changes hourly) source code for the product? I don't profess to know their reasons for or against this idea, but to them, it's probably an unnecesary support burden and effort that really could better be expended on product development.

[bfarber]

Then again though, think about it from their perspective - is there any value to be added by providing access to the latest "golden syrup" (AKA may not work, changes hourly) source code for the product? I don't profess to know their reasons for or against this idea, but to them, it's probably an unnecesary support burden and effort that really could better be expended on product development.

This is my view on it. We'll get no real benefit out of doing this, save maybe 1% of our customers who might find it nice, and would probably never use it in a real setup anyways, however we will have huge support and development burdens. We'll need to maintain this repo, which would presumably be different from our development repo. We'd need to maintain authentication to this repository, and audit the logins to verify our source code isn't being accessed without a license. We'll have users who don't know what they're doing that will still want to use the repo, even though it's unnecessary, asking for help doing so. All in all, it's a lot of work, and like I said, I'd forsee 1% or less of our customers actually using it, so I don't see any real benefit for us.

[Jaggi]

I'm sure the wheel was hard to invent first time round and i don't think many people used it then either but look at it go now :P. I can't comment on %'s of customers that would use and it wouldn't that hard to maintain you can just do a code sync with your repositry when you do a release. I'm not asking for hourly releases just an easier way to update our forums. Sod you giving the support thought that what the peer to peer area was for?

[Sire]

We could probably setup our own repository? Download the update, commit them into our own local repo, and then use svn with it. Haven't tried it yet or thought it out much further.

[Digi]

I have a local repo we use internally for our IPB projects. On each release I patch the "dev ready" trunk to the new changes, tag the old versions of IPB so we can come back to them if a client has an older form, and easily "update" all new projects from SVN. It works quite well for our needs and there's no restriction to doing this :)

I'd love snapshot access, but I can see how this would be a mangement nightmare. Just think on it, NDAs, ACLs, etc... It's nuts when you think about it. I wouldn't envy the person taht had to deal with it all :P I don't, however, see how I actually have a need for snapshot access. Even if I am working on a modification where a bug is the problem, I still have to release the mod ont he current version of IPB. I can't just patch the file (or even provide a patch)and release to a customer, that'd be against the license. So what good would snapshot/svn access do me really?

[henke37]

About the ease of setting up with a db, using svn over http with apache uses the normal apache authorization system. So it is feasible to rig it up properly.
About keeping it closed, seriously, you are already doing an automated authorization for the normal downloads, use the same credentials.