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

RE: SVN Feature Request: Selecting the revision for pinning externals

From: Bert Huijben <bert_at_qqmail.nl>
Date: Sat, 3 Sep 2016 16:34:34 +0200

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: zaterdag 3 september 2016 12:49
> To: Alfred von Campe <alfred_at_von-campe.com>
> Cc: Bert Huijben <bert_at_qqmail.nl>; Israel Sadeh <israel.sadeh_at_rtc-
> vision.com>; users_at_subversion.apache.org
> Subject: Re: SVN Feature Request: Selecting the revision for pinning externals
>
> On Fri, Sep 02, 2016 at 09:15:50PM -0400, Alfred von Campe wrote:
> > On Sep 2, 2016, at 16:22, Stefan Sperling <stsp_at_elego.de> wrote:
> >
> > > If you need a specific set of property changes in your tag, you
> > > can create a working copy which contains the necessary changes
> > > and then copy this working copy to a tag.
> >
> > Yes, I understand this, but...
> >
> > > We cannot automate details of everybody's build processes in SVN. Sorry.
> >
> > Again, I am in complete agreement. I was just wondering if it was
> > even considered to use the ‘{DATE}’ revision format as a parameter
> > to --pin-externals. Let’s say I ran a release build at last Monday
> > and today I decide to create a tag. If I know that my checkout (or
> > the svn update) finished at noon, then all externals that are not
> > already pegged must be from that time or earlier. So running the
> > command "svn cp —-pin-externals -r '{2016-08-29 12:00:00}'" should
> > "do the right thing" for most of the scenarios you can imagine.
>
> OK, I see how this might work. The code at present does a lookup
> of the HEAD revision (svn_ra_get_latest_revnum() call inside the
> pin_externals_prop() function in libsvn_client/copy.c). If we could
> pass a timestamp into that function we could ask the repository to
> resolve a dated revision instead.

This might work, but in cases like older dates on the ASF repository it will certainly break

> However, it's not immediately clear what this would do in the WC->WC
> and WC->REPOS copy scenarios, which currently pin to the WC BASE rev
> instead of HEAD since we want to mirror the WC state in the resulting
> copy. Should these cases keep ignoring -r? If so, is the upside of
> this feature worth the downside of an inconsistent UI?

For this specific user scenario it might be better to just take the local revisions as pin revisions on WC->REPOS and WC->WC than HEAD.

Or start by making a tag, and building from there... deleting or copying the tag when done, as date tricks aren't guaranteed to work anyway.

        Bert
Received on 2016-09-03 16:34:48 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.