subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: SVN Feature Request: Selecting the revision for pinning externals
Date Sat, 03 Sep 2016 14:34:34 GMT


> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: zaterdag 3 september 2016 12:49
> To: Alfred von Campe <alfred@von-campe.com>
> Cc: Bert Huijben <bert@qqmail.nl>; Israel Sadeh <israel.sadeh@rtc-
> vision.com>; users@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@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




Mime
View raw message