[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn????????

From: Johan Corveleyn <johan.corveleyn_at_uz.kuleuven.ac.be>
Date: Sat, 2 May 2009 00:42:30 +0200

I don't really understand where you got the idea that we use the file:// protocol :). No, we have a very sane setup (I think): repository is owned by a special user account, which is also used to run the Apache server that goes with it. We access it through https, authenticating with LDAP. We were only talking about sharing a *working copy* (on a build machine) for "release build" purposes.

For our continuous builds we use Teamcity (which idd doesn't need write access).

Regards,
Johan

> So, um.... who's the user that owns the Subversion repository and runs
> the Subversion server process? Please don't tell me you all use the
> file:// protocol in order to get around this security issue.
>
> If you use Hudson <https://hudson.dev.java.net/> with Subversion, you
> really wouldn't need to give the Hudson server write access to your
> Subversion repository. In Subversion, you can use the Subversion
> revision number as a psudo-tag, so you don't have to make a new tag
> for each build. Hudson shows you the Subversion revision number of
> each build. Hudson will also store your build artifacts and other
> items, so you don't have to check those into Subversion either.
>
> Give Hudson a try. It's really very easy to setup and use.
>
> On Thu, Apr 30, 2009 at 9:51 AM, Johan Corveleyn
> <johan.corveleyn_at_uz.kuleuven.ac.be> wrote:
> > Well that would be fine, except for security: you'd need to have a
> generic "build user" (not corresponding to a real person), with fixed
> password, that has write access to the repository (needs to commit
> version info, make branches, tags, ...). In our case this means this
> "user" has to exist in our LDAP in the developers group (only that LDAP
> group has write access currently).
> >
> > Our sysadmins don't like such generic user accounts (for one thing:
> their password tends to be fixed over time to help all the automation,
> contrary to normal accounts, which are forced to change their password
> every x months).
> >
> > That's why we thought: why not let every developer build under his
> own account (but share the WC to speed up things), and avoid this whole
> issue.
> >
> > Johan
> >
> > -----Oorspronkelijk bericht-----
> > Van: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> > Verzonden: donderdag 30 april 2009 15:43
> > Aan: Bob Archer
> > CC: Johan Corveleyn; users_at_subversion.tigris.org; xuer811
> > Onderwerp: Re: svn????????
> >
> > Bob Archer wrote:
> >>> Hmmm, we were planning to do this in the following scenario:
> >>> - during normal development, everyone has his own local WC
> >>> - for building, we use a fixed build machine (*nix machine) with a
> >>> "shared" WC (we take rotations to perform the build)
> >>>
> >>> I guess this sort of WC-sharing should be fine, shouldn't it?
> >>
> >> Yes it "should" be ok. However, why not create a build script and
> automate it. First, this means only the "automation" is using the WC.
> And second, your devs don't have to do it manually.
> >>
> >
> > Or start with something like hudson and let it run your automation.
> >
> > --
> >   Les Mikesell
> >    lesmikesell_at_gmail.com
> >
> > ------------------------------------------------------
> >
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessage
> Id=1995411
> >
> > To unsubscribe from this discussion, e-mail: [users-
> unsubscribe_at_subversion.tigris.org].
> >
>
>
>
> --
> David Weintraub
> qazwart_at_gmail.com

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2020906

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-02 00:43:25 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.