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

2016-09-02 Thread Alfred von Campe 
On Sep 2, 2016, at 16:22, Stefan Sperling  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

2016-09-02 Thread Stefan Sperling 
On Fri, Sep 02, 2016 at 01:48:03PM -0400, Alfred von Campe wrote:
> On Sep 2, 2016, at 4:07, Bert Huijben  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

2016-09-02 Thread Alfred von Campe 
On Sep 2, 2016, at 4:07, Bert Huijben  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: CLI SVN LOG E220001: Item not readable

2016-09-02 Thread Billy Buzzard 
Daniel the configuration is very similar to mine and it only partially works.  
Did you test your configuration by using "svn log" from the command line?   I 
did and it still has the same problem.

D:\projects\foo>svn log svn://myrepo/projects/foo
svn: E220001: Item is not readable  

The only way the "svn log" works that I have read about or found is when the 
admin adds * = r to the root folder in the authz file.  

-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: Friday, September 02, 2016 12:38 PM
To: Billy Buzzard
Cc: users@subversion.apache.org
Subject: Re: CLI SVN LOG E220001: Item not readable

Billy Buzzard wrote on Fri, Sep 02, 2016 at 15:28:11 +:
> What do I do if I have a group of trusted developers who are allowed 
> to see all projects and another group of non-so-trusted developers who 
> are only allowed to see their project?

This:

[groups]
trusted = ...
untrusted = ...

[/]
@trusted = rw
@untrusted =

[/projects/foo]
@untrusted = rw

[/projects/baz]
@untrusted = rw

Now if /projects/bar exists, people in @untrusted [who aren't also in @trusted] 
won't see it.  

You don't need $anonymous since members of both @dev1 and @dev2 are 
authenticated.

Cheers,

Daniel

> My authz file looks like this:
> 
> [groups]
> dev1 = billy, chuck
> dev2 = jim, bob
> 
> [/]
> $anonymous =
> @dev1 = rw
> 
> [/Project2]
> @dev2 = rw
> 
> If I use this authz as is then the svn log command does not work.  If I give 
> everyone read access it works, but now the non-so-trusted developers can see 
> projects that I do not want them to see.
> 
> I using svn, version 1.6.11 (r934486) on a 64-bit Linux machine.  I am 
> executing the svn log command from a 64 bit Windows 7 machine.  I am not 
> using httpd.

Re: CLI SVN LOG E220001: Item not readable

2016-09-02 Thread Daniel Shahaf 
Billy Buzzard wrote on Fri, Sep 02, 2016 at 15:28:11 +:
> What do I do if I have a group of trusted developers who are allowed
> to see all projects and another group of non-so-trusted developers who
> are only allowed to see their project? 

This:

[groups]
trusted = ...
untrusted = ...

[/]
@trusted = rw
@untrusted =

[/projects/foo]
@untrusted = rw

[/projects/baz]
@untrusted = rw

Now if /projects/bar exists, people in @untrusted [who aren't also in
@trusted] won't see it.  

You don't need $anonymous since members of both @dev1 and @dev2 are
authenticated.

Cheers,

Daniel

> My authz file looks like this:
> 
> [groups]
> dev1 = billy, chuck
> dev2 = jim, bob
> 
> [/]
> $anonymous =
> @dev1 = rw
> 
> [/Project2]
> @dev2 = rw
> 
> If I use this authz as is then the svn log command does not work.  If I give 
> everyone read access it works, but now the non-so-trusted developers can see 
> projects that I do not want them to see.
> 
> I using svn, version 1.6.11 (r934486) on a 64-bit Linux machine.  I am 
> executing the svn log command from a 64 bit Windows 7 machine.  I am not 
> using httpd.

CLI SVN LOG E220001: Item not readable

2016-09-02 Thread Billy Buzzard 
I want to restrict read access to a given respository to specific users, but 
when I do and I try to do an "svn log" from the command line I get an error 
message saying "E220001: Item not readable".  I have read several articles that 
say you must give everyone read access ( * = r ) for the svn log to work.  My 
repository structure looks like this:

/var/svn/Project1
/var/svn/Project1/branches
/var/svn/Project1/tags
/var/svn/Project1/trunk

/var/svn/Project2
/var/svn/Project2/branches
/var/svn/Project2/tags
/var/svn/Project2/trunk

What do I do if I have a group of trusted developers who are allowed to see all 
projects and another group of non-so-trusted developers who are only allowed to 
see their project?  My authz file looks like this:

[groups]
dev1 = billy, chuck
dev2 = jim, bob

[/]
$anonymous =
@dev1 = rw

[/Project2]
@dev2 = rw

If I use this authz as is then the svn log command does not work.  If I give 
everyone read access it works, but now the non-so-trusted developers can see 
projects that I do not want them to see.

I using svn, version 1.6.11 (r934486) on a 64-bit Linux machine.  I am 
executing the svn log command from a 64 bit Windows 7 machine.  I am not using 
httpd.

Unable to complete branch to trunk reintegration: missing revision on branch but file at issue does not exist for revision

2016-09-02 Thread Paul Delany 
Hi

Having a reintegration merge issue. Have raised this on stackoverflow
(http://stackoverflow.com/questions/39106047/unable-to-complete-svn-branch-to-trunk-reintegration-missing-revision-on-branch)

Have scanned the manual, and searched online, but not finding my issue:

In preparation for reintegration merge of a branch into trunk, I've updated 
merged the trunk
into the branch and committed
when I go to reintegrate merge the branch back into trunk I get:

svn merge -v --reintegrate https://example.com/repo/branches/branch_x .

svn: E195016: Reintegrate can only be used if revisions 2891 through 4343 were 
previously merged
from https://example.com/repo/trunk to the reintegrate source,
but this is not the case: branches/branch_x/somepath/component.js
Missing ranges: /trunk/branch_x/somepath/component.js:3709


I've resolved this type of issue before by going back to the branch and update 
merging just the revision / range
in question into the branch before reattempting the reintegration. However, 
this particular file does
not exist in trunk for the revision in question, so when I try this I get:

svn merge -c 3709 https://example.com/repo/trunk/somepath/component.js 
somepath/component.js
svn: E160013: '/repo/!svn/rvr/3708/trunk/somepath/component.js' path not found

Can anyone advise what I'm overlooking? Many thanks in advance.

Thanks
Paul

The information in this email is confidential and may be legally privileged.  
It may not represent the views of the SSE Group.  It is intended solely for the 
addressees.  Access to this email by anyone else is unauthorised.  If you are 
not the intended recipient, any disclosure, copying, distribution or any action 
taken or omitted to be taken in reliance on it, is prohibited and may be 
unlawful.  Any unauthorised recipient should advise the sender immediately of 
the error in transmission.  Unless specifically stated otherwise, this email 
(or any attachments to it) is not an offer capable of acceptance or acceptance 
of an offer and it does not form part of a binding contractual agreement. 

SSE Renewables Holdings Limited is part of the SSE Group 
The Registered Office of SSE Renewables Holdings Limited is Red Oak South, 
South County Business Park, Leopardstown, Dublin 18, Ireland. 
Registered in Ireland No. 314061 
www.sserenewables.com

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

2016-09-02 Thread Bert Huijben 
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.sa...@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.

  www.rtc-vision.com