You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Israel Sadeh <is...@rtc-vision.com> on 2016/09/01 16:46:52 UTC

SVN Feature Request: Selecting the revision for pinning externals

Hi,

The new '-pin-externals' switch of the 'svn copy' command pins the externals to their latest version.
This makes sense when copying the latest revision, but in case the copied branch is from an older revision, it also makes sense to pin the externals to the old revision.
This way in case it will be possible to create a tag from an old revision, and not only from the latest one.

My suggestion:  Add an optional pinning-revision parameter to the '-pin-externals' switch.
By default (if the pinning-revision' parameter isn't set)  - the externals will be pinned to the latest version.
If the parameter is set - the externals will be pinned to the parameter revision.
Best regards,

Israel Sadeh

[Description: Description: logo]

Israel Sadeh
Software Engineer
RTC Vision Ltd.
www.rtc-vision.com<http://www.rtc-vision.com/>



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

Posted by Bert Huijben <be...@qqmail.nl>.

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




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

Posted by Stefan Sperling <st...@elego.de>.
On Fri, Sep 02, 2016 at 09:15:50PM -0400, Alfred von Campe wrote:
> On Sep 2, 2016, at 16:22, Stefan Sperling <st...@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 \u2018{DATE}\u2019 revision format as a parameter
> to --pin-externals.  Let\u2019s 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 \u2014-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?

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

Posted by Alfred von Campe <al...@von-campe.com>.
On Sep 2, 2016, at 16:22, Stefan Sperling <st...@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.

Alfred


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

Posted by Stefan Sperling <st...@elego.de>.
On Fri, Sep 02, 2016 at 01:48:03PM -0400, Alfred von Campe wrote:
> On Sep 2, 2016, at 4:07, Bert Huijben <be...@qqmail.nl> wrote:
> > 
> > A single argument specifying a revision may only work for very specific scenarios. The --pin-externals feature also works when you have dozens of externals, all pointing towards different repositories.
> 
> Right, but could you consider the following scenario?  We typically
> create tags after a successful release build, and it would be great
> that the tag had all the externals pinned to those that were used at
> the time of the build.

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.

  svn co trunk-url working-copy
  cd working-copy
  svn propedit/propset svn:externals ...
  svn cp . ^/tags/1.0.0

We cannot automate details of everybody's build processes in SVN. Sorry.

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

Posted by Alfred von Campe <al...@von-campe.com>.
On Sep 2, 2016, at 4:07, Bert Huijben <be...@qqmail.nl> wrote:
> 
> A single argument specifying a revision may only work for very specific scenarios. The --pin-externals feature also works when you have dozens of externals, all pointing towards different repositories.

Right, but could you consider the following scenario?  We typically create tags after a successful release build, and it would be great that the tag had all the externals pinned to those that were used at the time of the build.  Well, we do know when the build started, so if—pin-externals would accept a ‘{DATE}’ revision, it would solve most of the scenarios.  Of course, externals that are already pinned should not be affected by this.

Thoughts?

Alfred


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

Posted by Bert Huijben <be...@qqmail.nl>.
A single argument specifying a revision may only work for very specific
scenarios. The --pin-externals feature also works when you have dozens of
externals, all pointing towards different repositories.

 

When adding the feature we determined that we can't handle all these
additional cases using the generic copy api. This function really 'pins'
what a checkout would do at the time of the pinning. going any further would
require much manual work from the user, which he/she could already do before
we added this. (Update working copy manually, and commit by using svn cp
PATH URL. Perhaps revert the local copy after this)

 

                Bert

 

From: Israel Sadeh [mailto:israel.sadeh@rtc-vision.com] 
Sent: donderdag 1 september 2016 18:47
To: users@subversion.apache.org
Subject: SVN Feature Request: Selecting the revision for pinning externals

 

Hi,

 

The new '-pin-externals' switch of the 'svn copy' command pins the externals
to their latest version.

This makes sense when copying the latest revision, but in case the copied
branch is from an older revision, it also makes sense to pin the externals
to the old revision.

This way in case it will be possible to create a tag from an old revision,
and not only from the latest one.

 

My suggestion:  Add an optional pinning-revision parameter to the
'-pin-externals' switch.

By default (if the pinning-revision' parameter isn't set)  - the externals
will be pinned to the latest version.

If the parameter is set - the externals will be pinned to the parameter
revision.

 

Best regards,

 

Israel Sadeh

 



 

Israel Sadeh
Software Engineer 

RTC Vision Ltd.

 <http://www.rtc-vision.com/> www.rtc-vision.com