[os-infrastructure] Pragmatic Version Control using Subversion
Grant Croker
grant.croker at ingres.com
Wed May 14 11:20:47 PDT 2008
Steve et al.
I have setup a SVN 1.5 repository based on http://code.ingres.com/ingres
on qasling6.ingres.prv. The repository is located at
https://qalings6.ingres.prv/repos/svnplay. To check out use the
following command:
svn co https://qalings6.ingres.prv/repos/svnplay
Authentication for commits is based on your domain login id/pmfkey and
password. If, like me, your local user is not your domain id you will
need to specify it at commit time using the '--username' command:
19:35:46 > svn ci --username crogr01 -m "test commit auth" test.grant
Authentication realm: <https://qasling6:443> the ingres.prv domain
Password for 'crogr01':
Deleting test.grant
Committed revision 34.
In order to protect domain login/passwords the svn server is setup using
SSL and will not accept non-secure connections for SVN operations. The
certificate used to secure the connection was self-signed you will be
prompted to reject, accept temporarily or accept permanently the
certificate:
Error validating server certificate for 'https://qasling6:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: qasling6.ingres.prv
- Valid: from Wed, 14 May 2008 17:51:59 GMT until Thu, 14 May 2009
17:51:59 GMT
- Issuer: Engineering, Ingres Corp, Islandia, New York, US
- Fingerprint: 34:fc:66:10:75:03:b6:d7:f8:6b:1e:e1:7c:8a:34:9d:71:b5:a0:8d
(R)eject, accept (t)emporarily or accept (p)ermanently?
Either accept temporarily or permanently, the former will prompt you
every time you connect to the svn server.
I am not 100% certain that the release of subversion on qasling6 is the
latest in the 1.5 series. If any one has any problems please let me know
and I will investigate further. If anyone believes it would be useful to
have all commits to svnplay sent out to an email list, let me know and I
will get it set-up.
regards
grant
Stephen Ball wrote:
> Yes, I remember I had to build Subversion from source because the distributed version was incompatible with just about everything on the archaic OS level we were using; it's probably easiest to just blow away everything and start from scratch, although you may have to build from source as I did; you may also have to jerk with httpd.
>
> Steve
>
> -----Original Message-----
> From: opensource-infrastructure-bounces at lists.ingres.com [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of Grant Croker
> Sent: Wednesday, May 14, 2008 9:12 PM
> To: Discussions about the infrastructure needed to support a true open sourcecommunity
> Cc: Jeremy M. Hankinson; Christopher M. Hane
> Subject: Re: [os-infrastructure] Pragmatic Version Control using Subversion
>
> Steve,
>
> qasling6 has two copies of svn, the system one as well as your
> hand-installed release (a 1.1.0 RC from what I can tell). I will remove
> the system provided server since it is even older and get the latest 1.5
> code installed.
>
> regards
>
> grant
>
>
> Stephen Ball wrote:
>
>> Hehe...qasling6 is an ideal server for this and it already has a copy of Subversion 1.5 server installed; the interesting coincidence is that the copy of Subversion on that machine is causing an update conflict with up2date right now....what is even funnier is that I think I'm the person that installed Subversion on that machine....way before Andrew cooked up this whole Subversion thing (12-18 months ago) I had been playing around with Subversion and had set it up as a WebDAV server to use for document storage and versioning, and I think I used qasling6.
>>
>> I say we just blow off the updates on this qasling6, unentitle it from RedHat, and set it up as an internal Subversion server.
>>
>> Steve
>>
>> -----Original Message-----
>> From: opensource-infrastructure-bounces at lists.ingres.com [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of Grant Croker
>> Sent: Wednesday, May 14, 2008 7:43 PM
>> To: Discussions about the infrastructure needed to support a true open sourcecommunity
>> Cc: Jeremy M. Hankinson; Christopher M. Hane
>> Subject: Re: [os-infrastructure] Pragmatic Version Control using Subversion
>>
>> I can set this up - If there is a preferred machine to do it on please
>> let me know.
>>
>> regards
>>
>> grant
>>
>> Stephen Ball wrote:
>>
>>
>>> I think the principal applies to any action that makes a copy,
>>> including tagging, but I haven’t tested it.
>>>
>>>
>>>
>>> Andrew, it would be nice to have an svn_play repository, even if it’s
>>> internal only, just like we have a picplay one in piccolo, to test
>>> this kind of thing.
>>>
>>>
>>>
>>> Steve
>>>
>>>
>>>
>>> *From:* opensource-infrastructure-bounces at lists.ingres.com
>>> [mailto:opensource-infrastructure-bounces at lists.ingres.com] *On Behalf
>>> Of *Bodo Bergmann
>>> *Sent:* Tuesday, May 13, 2008 8:49 PM
>>> *To:* Discussions about the infrastructure needed to support a true
>>> opensourcecommunity; Alex Hanshaw
>>> *Subject:* RE: [os-infrastructure] Pragmatic Version Control using
>>> Subversion
>>>
>>>
>>>
>>> Steve,
>>>
>>>
>>>
>>> the manual says in the "Cheap Copies" part:
>>>
>>> The main point here is that copies are cheap, both in time and space.
>>> If you create a branch entirely within the repository
>>> (by running *svn copy URL1 URL2*), it's a quick, constant-time operation.
>>>
>>> But in case of taking a label (tagging) we don't do a "svn copy URL1
>>> URL2".
>>>
>>> The copy is rather done from a local working copy to a URL (svn copy
>>> my-working-copy http://svn.example.com/repos/calc/tags/mytag),
>>>
>>> so I'm not sure if the same "cheap copy" mechanism applies there too.
>>>
>>> Bodo.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:* opensource-infrastructure-bounces at lists.ingres.com
>>> [mailto:opensource-infrastructure-bounces at lists.ingres.com] *On Behalf
>>> Of *Stephen Ball
>>> *Sent:* Tuesday, May 13, 2008 12:30 PM
>>> *To:* Alex Hanshaw
>>> *Cc:* Discussions about the infrastructure needed to support a true
>>> opensourcecommunity
>>> *Subject:* RE: [os-infrastructure] Pragmatic Version Control using
>>> Subversion
>>>
>>> Hi Alex,
>>>
>>>
>>>
>>> Actually, the manual doesn’t make it completely clear exactly when the
>>> links are used and broken, so I’m not completely sure since I haven’t
>>> actually tried it. Assuming we’re talking entirely about the server
>>> rather than the client, the manual seems to imply that the links are
>>> created when the branch is taken, and then people might edit the files
>>> in the branch, and once they commit their changes back to the server
>>> the link is broken on the server and replaced with the updated file. I
>>> assume that if the client contains a copy of both the trunk and the
>>> branch, it will contain multiple copies of the files rather than links
>>> (as it does in piccolo). The description is in the section named
>>> “cheap copies” here:
>>>
>>>
>>>
>>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
>>>
>>>
>>>
>>> The implication is that taking branches doesn’t cost you disk space
>>> unless you change something in them.
>>>
>>>
>>>
>>> Steve
>>>
>>>
>>>
>>> *From:* Alex Hanshaw
>>> *Sent:* Tuesday, May 13, 2008 8:00 PM
>>> *To:* Stephen Ball
>>> *Cc:* Discussions about the infrastructure needed to support a true
>>> opensource community
>>> *Subject:* RE: [os-infrastructure] Pragmatic Version Control using
>>> Subversion
>>>
>>>
>>>
>>> Hi Steve
>>>
>>> I can't see how svn could be using links in this situation. What step
>>> would break the link and provide a local copy? There's no concept of
>>> an "open" and
>>> editing the file would change the tag and the original file in one hit.
>>> Working through the steps to create a TAG no directory or local copy
>>> is established until you checkout the TAG. If you are are suggesting
>>> that svn
>>> maintains files revision information in the repository and then
>>> creates a copy for the TAG branch IF changes are made in the tag, that
>>> makes sense because there
>>> is no local visible copy until you check out the TAG.
>>>
>>> Alex
>>>
>>> On Mon, 2008-05-12 at 20:21 -0400, Stephen Ball wrote:
>>>
>>> Actually Subversion branching works much like piccolo branching, the
>>> branches themselves are implemented as hard links on the server until
>>> someone changes one of the files in the branch, at which time the link
>>> is broken and replaced with a real file; so the disk implications of a
>>> branch are very small…In any case disk is cheap.
>>>
>>>
>>>
>>> In piccolo taking a branch does normally take a few hours and numerous
>>> branches eventually cause performance issues in the database, but the
>>> time and performance problem in piccolo is largely a design issue, the
>>> database itself was never designed with the intention of branching
>>> numerous (over 8,000) files numerous times. We shouldn’t assume that
>>> in Subversion branching either takes a long time or causes database
>>> performance issues, we need to test that aspect of it; since Grant has
>>> taken a branch already he may be able to add some input.
>>>
>>>
>>>
>>> The one thing I’m worried about is the maintenance problem of numerous
>>> branches; as far as I can see we can’t avoid taking numerous branches
>>> of the code in order to get the features we need (my read on the
>>> documentation is the same as Alex’s, we need to make a branch in order
>>> to get a non head-rev tag), so how do we keep track of all the
>>> branches and make sure the whole things doesn’t become a big mess?
>>>
>>>
>>>
>>> If anyone is interested, I have managed to install a version of the
>>> Subversive plug-in for Eclipse, and have it running against our
>>> repository. If we are to get a grip on branch maintenance, a GUI tool
>>> has to be in the picture, and Subversive looks promising. I have it
>>> all rolled up into a VMWare VM running SuSE Linux if anyone wants a
>>> copy; the VM includes SuSE 10.3, all the pre-requisites needed to
>>> build Ingres pulled directly from the SuSE repository, a copy of
>>> Eclipse with the CDT and the Subversive plug-in, and a complete
>>> pre-built copy of Ingres from about a week ago.
>>>
>>>
>>>
>>> Steve
>>>
>>>
>>>
>>> IngresLogo_Color
>>>
>>>
>>>
>>> Steve Ball
>>>
>>> Direcor, Ingres DBMS Development
>>>
>>> *Ingres Corporation*
>>>
>>> stephen.ball at ingres.com <mailto:first.last at ingres.com>
>>>
>>>
>>>
>>> *www.ingres.com <http://www.ingres.com>*
>>>
>>>
>>>
>>> This transmission is confidential and intended solely for the use
>>> of the recipient named above. It may contain confidential,
>>> proprietary, or legally privileged information. If you are not the
>>> intended recipient, you are hereby notified that any unauthorized
>>> review, use, disclosure or distribution is strictly prohibited. If
>>> you have received this transmission in error, please contact the
>>> sender by reply e-mail and delete the original transmission and
>>> all copies from your system.
>>>
>>>
>>>
>>> *From:*opensource-infrastructure-bounces at lists.ingres.com
>>> [mailto:opensource-infrastructure-bounces at lists.ingres.com] *On
>>> Behalf Of *Bodo Bergmann
>>> *Sent:* Tuesday, May 13, 2008 1:51 AM
>>> *To:* Alex Hanshaw; Discussions about the infrastructure needed to
>>> support a trueopensource community; OpenSourceInfrastructure
>>> *Subject:* AW: [os-infrastructure] Pragmatic Version Control using
>>> Subversion
>>>
>>>
>>>
>>> Yes, that's what I've already added to the Wiki page.
>>>
>>>
>>>
>>>
>>>
>>> But this implementation is both a waste of disk resources on the
>>> server
>>>
>>> and also has a huge performance impact as
>>>
>>> creating a label is not just a matter of seconds but will probably
>>> take several minutes.
>>>
>>>
>>>
>>>
>>>
>>> Bodo.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *Von:*opensource-infrastructure-bounces at lists.ingres.com im
>>> Auftrag von Alex Hanshaw
>>> *Gesendet:* Mo 12.05.2008 08:02
>>> *An:* OpenSourceInfrastructure
>>> *Betreff:* [os-infrastructure] Pragmatic Version Control using
>>> Subversion
>>>
>>> Hi all
>>>
>>> So far one of the problem areas we've mentioned with regards to
>>> subversion is that there is no equivalent to a label.
>>> Some have already said "tags" do not provide the same functionality.
>>> However, in the above book I've just read "Tags can also be made
>>> from a mixed revision working copy - a set of files you've checked
>>> out that doesn't correspond to a single repository revision
>>> number". The book only arrived today, I check out the rest of the
>>> tags and branches section to see if this
>>> claim is true or not.
>>>
>>> Alex
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> opensource-infrastructure mailing list
>>> opensource-infrastructure at lists.ingres.com
>>> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> opensource-infrastructure mailing list
>> opensource-infrastructure at lists.ingres.com
>> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>>
>>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>
--
Grant Croker - Ingres PHP, Ruby and Python maintainer
I am fascinated by religion. (That's a completely different thing from
believing in it!) It has had such an incalculably huge effect on human
affairs. What is it? What does it represent? Why have we invented it?
How does it keep going? What will become of it? I love to keep poking
and prodding at it. I've thought about it so much over the years that
that fascination is bound to spill over into my writing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ingres.com/pipermail/opensource-infrastructure/attachments/20080514/ff40c610/attachment-0001.html
More information about the opensource-infrastructure
mailing list