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.
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?
Received on 2016-09-03 12:49:49 CEST