> -----Original Message----- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: zaterdag 3 september 2016 12:49 > To: Alfred von Campe <alf...@von-campe.com> > Cc: Bert Huijben <b...@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 <s...@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