[os-infrastructure] Pragmatic Version Control using Subversion
Grant Croker
grant.croker at ingres.com
Wed May 14 02:42:53 PDT 2008
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
>
--
Grant Croker - Ingres PHP, Ruby and Python maintainer
The Macintosh may only have 10% of the market, but it is clearly the top
10%.
More information about the opensource-infrastructure
mailing list