Re: --revision option is not forwarded to svn:externals references

Am 03.10.2022 um 15:53 schrieb Alfred von Campe: On Sep 28, 2022, at 7:10, Harald Oehlmann wrote: I will see, if I can work around it with SVN. I just told myself a fool, as I thought for 20 years, that this basic requirement was no problem, but it is. I’ve used a script that would enumera

Re: --revision option is not forwarded to svn:externals references

> On Sep 28, 2022, at 7:10, Harald Oehlmann wrote: > > I will see, if I can work around it with SVN. I just told myself a fool, as I > thought for 20 years, that this basic requirement was no problem, but it is. I’ve used a script that would enumerate the externals and used the ‘{DATE}’ form

Re: --revision option is not forwarded to svn:externals references

Am 28.09.2022 um 12:59 schrieb Daniel Sahlberg: Den ons 28 sep. 2022 kl 11:52 skrev Harald Oehlmann mailto:harald.oehlm...@elmicron.de>>: Am 28.09.2022 um 11:43 schrieb Daniel Sahlberg: > Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann > mailto:harald.oehlm...@elmicron.de>

Re: --revision option is not forwarded to svn:externals references

Den ons 28 sep. 2022 kl 11:52 skrev Harald Oehlmann < harald.oehlm...@elmicron.de>: > Am 28.09.2022 um 11:43 schrieb Daniel Sahlberg: > > Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann > > mailto:harald.oehlm...@elmicron.de>>: > > > > ( I have chosen the same title as SVN-2516, as it addr

Re: --revision option is not forwarded to svn:externals references

Am 28.09.2022 um 11:43 schrieb Daniel Sahlberg: Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann mailto:harald.oehlm...@elmicron.de>>: ( I have chosen the same title as SVN-2516, as it addresses the same issue ) Thank you for great subversion. I am a happy user with TortoiseSVN

Re: --revision option is not forwarded to svn:externals references

Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann < harald.oehlm...@elmicron.de>: > ( I have chosen the same title as SVN-2516, as it addresses the same issue > ) > > Thank you for great subversion. I am a happy user with TortoiseSVN on > Windows with a Linux server since 20 years. > > I was hit

--revision option is not forwarded to svn:externals references

( I have chosen the same title as SVN-2516, as it addresses the same issue ) Thank you for great subversion. I am a happy user with TortoiseSVN on Windows with a Linux server since 20 years. I was hit by a quality department request to restore a revision, I have tagged before. Unfortunately,

Re: This needs moderators? Re: Root-relative svn:externals result in error exporting a specific revision

Thanks for following up on this, Daniel! On Tue, Jul 18, 2017 at 6:01 AM, Daniel Shahaf wrote: > Pavel Lyalyakin wrote on Mon, 17 Jul 2017 13:31 +0300: > > On Sun, Jul 16, 2017 at 2:04 PM, Daniel Shahaf > > wrote: > > > [...] are you still actively moderating this list? > > > Do we need more m

Re: This needs moderators? Re: Root-relative svn:externals result in error exporting a specific revision

Pavel Lyalyakin wrote on Mon, 17 Jul 2017 13:31 +0300: > On Sun, Jul 16, 2017 at 2:04 PM, Daniel Shahaf > wrote: > > [...] are you still actively moderating this list? > > Do we need more moderators? > > If there is a need for a mailing list moderator, I'd be happy to take up > the duty. :) Tha

Re: This needs moderators? Re: Root-relative svn:externals result in error exporting a specific revision

Hello, On Sun, Jul 16, 2017 at 2:04 PM, Daniel Shahaf wrote: > [ bcc'd to dev@, users-owner@; please follow up to users@ ] > > Doug Brown wrote on Wed, 12 Jul 2017 17:34 -0700: > > … > > Doug reported earlier today that his message was not moderated to users@ > from Wednesday until just now. > >

Re: Root-relative svn:externals result in error exporting a specific revision

Doug Brown wrote on Wed, 12 Jul 2017 17:34 -0700: > svn: subversion/libsvn_subr/dirent_uri.c:324: canonicalize: Assertion > `*src != '/'' failed. > Aborted (core dumped) Thanks for the great bug report. I think I see the root cause: that the value of export_directory()'s parameter FROM_PATH_OR_UR

This needs moderators? Re: Root-relative svn:externals result in error exporting a specific revision

[ bcc'd to dev@, users-owner@; please follow up to users@ ] Doug Brown wrote on Wed, 12 Jul 2017 17:34 -0700: > … Doug reported earlier today that his message was not moderated to users@ from Wednesday until just now. What happened? Greg, Ed, Lorenz, are you still actively moderating this list?

Root-relative svn:externals result in error exporting a specific revision

eems to be related to svn:externals with root-relative URLs (^/). If I attempt to export a specific revision from a checkout, and that revision contains root-relative externals, svn will error out: svn: subversion/libsvn_subr/dirent_uri.c:324: canonicalize: Assertion `*src != '/'' fai

Re: Ignore svn:externals definition in some clients?

On Jul 6, 2017, at 04:24, Daniel Shahaf wrote: > We also have a branch that enables svn to checkout git trees natively [1], > but it's not even merged to trunk yet. > > [1] https://svn.apache.org/viewvc/subversion/branches/ra-git/ > W

Re: Ignore svn:externals definition in some clients?

Thorsten Schöning wrote on Thu, 06 Jul 2017 10:15 +0200: > So, is there some way for a SVN client to be configured in a way that > some svn:externals of some paths are ignored or something like that? Edit the svn:externals property in your working copy to remove that external, then run &

Ignore svn:externals definition in some clients?

Hi all, I have a large SVN repo containing various libs. Some of those are versioned as files within our own repo, some only referenced using svn:externals to be available in a local file tree always at the same place for all users. Some of those externals refer to native SVN repos, some use the

Re: "svn pget svn:externals -r . -R" dramatically slow

So, for the time being you could use this as a workaround, Andrey (if you're scripting this): checkout to a temp directory (or even aramdisk if it's not too big), and run the propget on that; then deletethe checkout. I can not afford to check out everything in the temp, it would be slower th

RE: "svn pget svn:externals -r . -R" dramatically slow

> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: donderdag 18 mei 2017 15:19 > To: users@subversion.apache.org > Cc: Andrey > Subject: Re: "svn pget svn:externals -r . -R" dramatically slow > > On 18.05.2017 13:51, Andrey w

Re: "svn pget svn:externals -r . -R" dramatically slow

On Thu, May 18, 2017 at 8:22 PM, Branko Čibej wrote: > On 18.05.2017 16:21, Andrey wrote: >> Stefan Sperling писал(а) в своём письме Thu, 18 May >> 2017 15:55:36 +0300: >> >>> And this, we have to admit, can be a problem for some use cases. >>> It would be nice to have an optimized way of doing t

Re: "svn pget svn:externals -r . -R" dramatically slow

On 18.05.2017 16:21, Andrey wrote: > Stefan Sperling писал(а) в своём письме Thu, 18 May > 2017 15:55:36 +0300: > >> And this, we have to admit, can be a problem for some use cases. >> It would be nice to have an optimized way of doing this, >> and I expect we would be open to suggestions and patc

Re: "svn pget svn:externals -r . -R" dramatically slow

Stefan Sperling писал(а) в своём письме Thu, 18 May 2017 15:55:36 +0300: And this, we have to admit, can be a problem for some use cases. It would be nice to have an optimized way of doing this, and I expect we would be open to suggestions and patches. I tested it a bit deeper. I checked out

Re: "svn pget svn:externals -r . -R" dramatically slow

On 18.05.2017 15:51, Andrey wrote: > Branko Čibej писал(а) в своём письме Thu, 18 May > 2017 16:19:23 +0300: > >>> may be add file content hash to represent 2 statuses of the same file >>> paths? At least it will protect file from accidental remove and miss >>> of add to commit? >> >> There will b

Re: "svn pget svn:externals -r . -R" dramatically slow

Branko Čibej писал(а) в своём письме Thu, 18 May 2017 16:19:23 +0300: may be add file content hash to represent 2 statuses of the same file paths? At least it will protect file from accidental remove and miss of add to commit? There will be no accidental remove; when you commit, your new fi

Re: "svn pget svn:externals -r . -R" dramatically slow

Johan Corveleyn писал(а) в своём письме Thu, 18 May 2017 15:51:01 +0300: Why just not to ignore them? Anyway they are don't have any mapping to a local directory. In general I think it's fine for a directory to have an empty svn:externals property (have not tested it, but I guess

Re: "svn pget svn:externals -r . -R" dramatically slow

On 18.05.2017 13:51, Andrey wrote: > Branko Čibej писал(а) в своём письме Thu, 18 May > 2017 14:41:17 +0300: > >>> However, I don't want to revert anything, i am talking about >>> possibility of forget to add files because they are obscured by the >>> deletion state in the status. >> >> So what do

Re: "svn pget svn:externals -r . -R" dramatically slow

On Thu, May 18, 2017 at 02:51:01PM +0200, Johan Corveleyn wrote: > (like Bert said, "There is no optimized code path > for retrieving properties recursively directly from the server.") And this, we have to admit, can be a problem for some use cases. It would be nice to have an optimized way of doi

Re: "svn pget svn:externals -r . -R" dramatically slow

On Thu, May 18, 2017 at 1:58 PM, Andrey wrote: >>> Why is that important when the links are empty? >> >> External references are stored in properties called svn:externals. >> I think Bert is referring to the retrieval of those properties. > > I meant an external

Re: "svn pget svn:externals -r . -R" dramatically slow

On Thu, May 18, 2017 at 02:58:51PM +0300, Andrey wrote: > > > Why is that important when the links are empty? > > External references are stored in properties called svn:externals. > > I think Bert is referring to the retrieval of those properties. > I meant an external re

Re: "svn pget svn:externals -r . -R" dramatically slow

file (FSFS) repository. * fs_x : Module for working with an experimental (FSX) repository. * fs_base : Module for working with a Berkeley DB repository. ``` Just as background: svn:externals definitions can also optionally take a peg revision (the @REV notation) [1], [2]. Maybe in the future you

Re: "svn pget svn:externals -r . -R" dramatically slow

file (FSFS) repository. * fs_x : Module for working with an experimental (FSX) repository. * fs_base : Module for working with a Berkeley DB repository. ``` Just as background: svn:externals definitions can also optionally take a peg revision (the @REV notation) [1], [2]. Maybe in the future you

Re: "svn pget svn:externals -r . -R" dramatically slow

Why is that important when the links are empty? External references are stored in properties called svn:externals. I think Bert is referring to the retrieval of those properties. I meant an external reference of cause. By the link i mean peace of string in the output from the "svn

Re: "svn pget svn:externals -r . -R" dramatically slow

Branko Čibej писал(а) в своём письме Thu, 18 May 2017 14:41:17 +0300: However, I don't want to revert anything, i am talking about possibility of forget to add files because they are obscured by the deletion state in the status. So what do you suggest we do instead? There's a file named 'f

Re: "svn pget svn:externals -r . -R" dramatically slow

On 18.05.2017 13:27, Andrey wrote: >>> As you see the file1.txt is missed in second status output as >>> unversioned and so can be missed from add before a commit. >> It's not unversioned, it's in the "deleted" state. You can't have both, >> since you can revert the deletion. > If i'll revert it th

Re: "svn pget svn:externals -r . -R" dramatically slow

repository. * fs_x : Module for working with an experimental (FSX) repository. * fs_base : Module for working with a Berkeley DB repository. ``` Just as background: svn:externals definitions can also optionally take a peg revision (the @REV notation) [1], [2]. Maybe in the future you can u

Re: "svn pget svn:externals -r . -R" dramatically slow

of this specific command is like running 'svn ls' on > > every directory + fetching the properties on every file and every > > directory. (It is slightly more optimized than that, but not much) > Why is that important when the links are empty? External references are

Re: "svn pget svn:externals -r . -R" dramatically slow

As you see the file1.txt is missed in second status output as unversioned and so can be missed from add before a commit. It's not unversioned, it's in the "deleted" state. You can't have both, since you can revert the deletion. If i'll revert it then i'll LOSE CHANGES because the svn will remove

Re: "svn pget svn:externals -r . -R" dramatically slow

Bert Huijben писал(а) в своём письме Thu, 18 May 2017 13:09:07 +0300: There is no optimized code path for retrieving properties recursively directly from the server. The implementation of this specific command is like running 'svn ls' on every directory + fetching the properties on every

RE: "svn pget svn:externals -r . -R" dramatically slow

> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: woensdag 17 mei 2017 19:57 > To: Andry > Cc: users@subversion.apache.org > Subject: Re: "svn pget svn:externals -r . -R" dramatically slow > > On Tue, May 16, 2017 at

Re: "svn pget svn:externals -r . -R" dramatically slow

e/Files - > > I think the 2 last records draws the svn mad and it begin to crawl the server > for something for about 1 minute. > > I tries variations of the command. For example all these having the same > result as above: > svn pget svn:externals -r "1193" "h

"svn pget svn:externals -r . -R" dramatically slow

ample all these having the same result as above: svn pget svn:externals -r "1193" "https://domain.ab/svn/proj2/trunk"; -R --non-interactive svn pget svn:externals -r "1193" "https://domain.ab/svn/proj2/trunk@1193"; -R --non-interactive svn pget svn:externals

What's the process when converting a directory to use svn:externals?

Server 1.9.3 (Windows) and client 1.8.15(Linux-Centos6.5) We are in the mist of refactoring our directory structure from the monolithic (Clearcase imported) directory structure to moving subdirectories to new repositories and using svn:externals with pegged versions back into the primary

Does svn:externals Support --depth?

I'm trying to use svn:externals to include a directory from repo B in working copies of repo A. I can change only repo A. The external directory is huge, but I want only a few immediate children. Is there a way to get what this implies from svn:externals? % svn proplist -v . Properti

Re: Is it safe to redirect from HTTP to HTTPS in case of svn:externals?

:-) > There are other options to specify your externals; see 'svn help propset' I know, but my example was simplified, my repos are still mainly hosted by different svnserve instances, so that URIs and Ports differ and such. I couldn't find anything better in the newer syntax for

RE: Is it safe to redirect from HTTP to HTTPS in case of svn:externals?

> -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: woensdag 19 augustus 2015 21:50 > To: users@subversion.apache.org > Subject: Is it safe to redirect from HTTP to HTTPS in case of svn:externals? > > Hi, > > I'm

Is it safe to redirect from HTTP to HTTPS in case of svn:externals?

Hi, I'm implementing publicly accessible mod_davn_svn in addition to some internally used svnserve. Some of my repos use svn:externals where we used to defined "//internal.example.org/...", my publicly available entry point is "https://external.example.org";. For the pub

Re: svndumptool and svn:externals

On Apr 20, 2015, at 6:56 AM, MOKRANI Rachid wrote: > I moved my SVN server, and now I need to change our svn:externals path. > > I saw that svndumptool can help me to do that, but I don't know exactly the > syntax command to run. > > > My old SVN server is: > htt

svndumptool and svn:externals

Hi, I moved my SVN server, and now I need to change our svn:externals path. I saw that svndumptool can help me to do that, but I don't know exactly the syntax command to run. My old SVN server is: http://my_old_server/ I can access to my SVN project with the URL : http://my_old_serve

Re: Moving a repository with svn:externals using absolute paths (URLs)

On Fri, Jun 20, 2014 at 5:30 AM, Ryan Schmidt wrote: > On Jun 18, 2014, at 8:19 PM, Nico Kadel-Garcia wrote: > I recommend "do". I had success with this method with my own repositories. > Now, I don't know what Nicolas' business requirements are with regard to the > immutability of old data; m

Re: Moving a repository with svn:externals using absolute paths (URLs)

On Jun 18, 2014, at 8:19 PM, Nico Kadel-Garcia wrote: > On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas > wrote: > >> We’ve been using svn successfully for years on a server, and now have to >> migrate to a new one. We are hit by the known issue of svn:externals &

Re: Moving a repository with svn:externals using absolute paths (URLs)

On 19.06.2014 05:11, Geoff Field wrote: >> From: Nico Kadel-Garcia >> On Wed, Jun 18, 2014 at 9:35 PM, Geoff Field wrote: >> >>> In our duplication effort, we also set all the permissions >>> on the old repositories to read-only, to limit the chances >>> of cross-contamination. > Just to be clear,

RE: Moving a repository with svn:externals using absolute paths (URLs)

> From: Nico Kadel-Garcia > On Wed, Jun 18, 2014 at 9:35 PM, Geoff Field wrote: > > > In our duplication effort, we also set all the permissions > > on the old repositories to read-only, to limit the chances > > of cross-contamination. Just to be clear, I'm not talking about the FILE permissions

Re: Moving a repository with svn:externals using absolute paths (URLs)

On Wed, Jun 18, 2014 at 9:35 PM, Geoff Field wrote: > In our duplication effort, we also set all the permissions on the old > repositories to read-only, to limit the chances of cross-contamination. > > Regards, > > Geoff This. So much this. When people want to keep, and keep cross-merging, the c

RE: Moving a repository with svn:externals using absolute paths (URLs)

wn issue of svn:externals containing absolute paths to the repo to be moved, since we started with versions <1.5 without support for relative URLs. We've been researching how to properly do this, knowing that we handle certified SW on that server, so losing data or corrupting the repo is not allowed

Re: Moving a repository with svn:externals using absolute paths (URLs)

On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas < nicolas.bris...@airbus.com> wrote: > Hi, > > > > We’ve been using svn successfully for years on a server, and now have to > migrate to a new one. We are hit by the known issue of svn:externals > containing absolute pa

Re: Moving a repository with svn:externals using absolute paths (URLs)

On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas < nicolas.bris...@airbus.com> wrote: > Hi, > > > > We’ve been using svn successfully for years on a server, and now have to > migrate to a new one. We are hit by the known issue of svn:externals > containing absolute pa

Moving a repository with svn:externals using absolute paths (URLs)

Hi, We’ve been using svn successfully for years on a server, and now have to migrate to a new one. We are hit by the known issue of svn:externals containing absolute paths to the repo to be moved, since we started with versions <1.5 without support for relative URLs. We’ve been researching

Re: "svn status -u" and svn:externals - bug?

patible-version 1.6 svn mkdir -mm file://`pwd`/repo/A ^/B svnmucc -mm propset svn:externals '^/A@1 A' file://`pwd`/repo/B svn mkdir -mm file://`pwd`/repo/A/C Using 1.7: $ svn1.7 co file://`pwd`/repo/B wc $ svn1.7 st -u wc Xwc/A Status against

Re: "svn status -u" and svn:externals - bug?

tzender: Rolf Leonhard; Geschäftsführung: Bernhard Bihr, > Hanno Miorini > Umsatzsteuer-Identnummer (VAT no.): DE 18 21 37 093, Steuernummer: > 99012/08009 > > > _ > Von: Bay Karsten (BEG/ESR3) > Gesendet: Freitag, 12. April 2013 15:49

WG: "svn status -u" and svn:externals - bug?

99012/08009 _ Von: Bay Karsten (BEG/ESR3) Gesendet: Freitag, 12. April 2013 15:49 An: 'users@subversion.apache.org' Betreff: "svn status -u" and svn:externals - bug? Hi SVN users, I searched for this problem in the open issues bu

"svn status -u" and svn:externals - bug?

Hi SVN users, I searched for this problem in the open issues but could not find a similar problem. Can you help me to find out if this is a known problem/bug? I have a repository with a few svn:externals. Some of them point to a specific revision (e.g. trunk@8) of their repository. When I look

Re: svn export selected parts of svn:externals

h the files in it and only one of the > > svn:externals, not the others. > > > > I do not want to refer to the repository where the externals are located > > in, because the script that does the > > Svn export should not (need to) know where they are. > > > > I tried

Re: svn export selected parts of svn:externals

On Mar 26, 2013, at 02:46, "Niemann, Hartmut" wrote: > I have a directory with some files and a list of svn:external > directories , and so on. > I want to svn export with the files in it and only one of the > svn:externals, not the others. > > I do not wan

svn export selected parts of svn:externals

Hello! I have a directory with some files and a list of svn:external directories , and so on. I want to svn export with the files in it and only one of the svn:externals, not the others. I do not want to refer to the repository where the externals are located in, because the script that

Re: Tagging svn:externals

> From: Les Mikesell > To: BRM > Cc: "users@subversion.apache.org" > Sent: Thursday, February 28, 2013 5:29 PM > Subject: Re: Tagging svn:externals > > On Thu, Feb 28, 2013 at 3:34 PM, BRM wrote: > >>> No, I think the choices are to tag from the

Re: Tagging svn:externals

On Thu, Feb 28, 2013 at 3:34 PM, BRM wrote: >> No, I think the choices are to tag from the working copy or commit a >> change after making the tag. But neither seem like the tool is >> designed to do what I'd expect to be a common operation cleanly. > > What do you mean? > > Branching from a wor

Re: Tagging svn:externals

> From: Les Mikesell > To: BRM > Cc: "users@subversion.apache.org" > Sent: Wednesday, February 27, 2013 5:49 PM > Subject: Re: Tagging svn:externals > > On Wed, Feb 27, 2013 at 4:44 PM, BRM wrote: >>> >>> Won't work - it

Re: Tagging svn:externals

On Wed, Feb 27, 2013 at 4:44 PM, BRM wrote: >> >> Won't work - it has to be committed somewhere or it won't be built. > > Perhaps then you need a different tool. > For example, git-svn[1] is might be what you want. > > When something is ready for QA it is pushed to a git repository for Jenkins >

Re: Tagging svn:externals

> From: Les Mikesell > To: BRM > Cc: "users@subversion.apache.org" > Sent: Wednesday, February 27, 2013 5:30 PM > Subject: Re: Tagging svn:externals > > On Wed, Feb 27, 2013 at 4:14 PM, BRM wrote: >>> >>> But that's not what I want.  I

Re: Tagging svn:externals

t;> that doesn't match any trunk commit. > > From that description, it'll have to be a manual process that you run from > within your working copy. > Just update the svn:externals appropriately and then do an "svn update". > You can test whatever you like withou

Re: Tagging svn:externals

> From: Les Mikesell > To: BRM > Cc: "users@subversion.apache.org" > Sent: Tuesday, February 26, 2013 6:12 PM > Subject: Re: Tagging svn:externals > > On Tue, Feb 26, 2013 at 4:29 PM, BRM wrote: >> >>> How can a script possibly know the co

Re: Tagging svn:externals

pull the revision number to > generate the peg > revision information in the svn:externals data, essentially: > > ^/somePath@r1829 -r 1829 > > The "1829" portion is easily scriptable to find. But that's not what I want. I want the externals in tags to point to previ

Re: Tagging svn:externals

> From: Les Mikesell > To: BRM > Cc: "users@subversion.apache.org" > Sent: Tuesday, February 26, 2013 11:56 AM > Subject: Re: Tagging svn:externals > > On Tue, Feb 26, 2013 at 8:48 AM, BRM wrote: >>>> >>> Agreed, but the scenario is makin

Re: Tagging svn:externals

t;> plugin that allows tagging after a build. > > It's fully a matter of how you structure release process for anyone. > If you keep trunk prestine, then I don't think that would be an issue - your > process just has to say that trunk > can only have released svn:e

Re: Tagging svn:externals

> From: Les Mikesell > To: BRM > Cc: "users@subversion.apache.org" > Sent: Friday, February 22, 2013 10:57 AM > Subject: Re: Tagging svn:externals > On Fri, Feb 22, 2013 at 9:02 AM, BRM wrote: >>>>   Not only does it solve the above, but it also enfor

Re: Tagging svn:externals

adjusted for the needs of real-world use. So there's a problem either >> way > > All true. But that's what your release process is for. Part of my release > process for the projects that use svn:externals is to first tag and release > any externals that are not

Re: Tagging svn:externals

> From: Les Mikesell > To: BRM > Cc: "users@subversion.apache.org" > Sent: Thursday, February 21, 2013 11:09 AM > Subject: Re: Tagging svn:externals > > On Thu, Feb 21, 2013 at 9:42 AM, BRM wrote: >> >>> On Wed, Feb 20, 2013 at 11:52 AM, B

Re: Tagging svn:externals

On Feb 21, 2013, at 11:18, Philip Martin wrote: > Les Mikesell writes: > >> Neither choice 'feels' quite right to me unless you have an >> intermediate branch to make the change. That is, if you make it on >> the trunk before you copy to the tag you break the likely continuing >> work on the tr

Re: Tagging svn:externals

Les Mikesell writes: > Neither choice 'feels' quite right to me unless you have an > intermediate branch to make the change. That is, if you make it on > the trunk before you copy to the tag you break the likely continuing > work on the trunk that expects the externals to also follow trunk > com

Re: Tagging svn:externals

On Thu, Feb 21, 2013 at 9:42 AM, BRM wrote: > >> On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer wrote: >>> Some clients like TortoiseSVN have a feature that will pin the external to >>> the revision you are copping when doing the tag. Otherwise, you have to do >>> it manually before or after yo

Re: Tagging svn:externals

> From: Les Mikesell > To: Bob Archer > Cc: C M ; "users@subversion.apache.org" > > Sent: Wednesday, February 20, 2013 1:03 PM > Subject: Re: Tagging svn:externals > > On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer wrote: >> Some  clients like Tort

Re: Tagging svn:externals

On Wed, Feb 20, 2013 at 12:30 PM, C M wrote: > I am not seeing anything in: /tags/Rel_1.0. > > Mind you I am using the Tortoise SVN 1.7 client to do the copy. Subversion commands don't recurse into the stuff pulled in with externals, if that is what you are expecting. But if the thing you tag h

Re: Tagging svn:externals

I am not seeing anything in: /tags/Rel_1.0. Mind you I am using the Tortoise SVN 1.7 client to do the copy. On Wed, Feb 20, 2013 at 12:05 PM, Les Mikesell wrote: > On Wed, Feb 20, 2013 at 11:58 AM, C M wrote: > > The external definitions do specify a revision. That part is working > fine. > > >

Re: Tagging svn:externals

On Wed, Feb 20, 2013 at 11:58 AM, C M wrote: > The external definitions do specify a revision. That part is working fine. > > I am just not clear on why a simple copy (tag) doesn't work against > externals. What do you mean by 'doesn't work'? The copy should have the same externals as the sourc

Re: Tagging svn:externals

On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer wrote: > Some clients like TortoiseSVN have a feature that will pin the external to > the revision you are copping when doing the tag. Otherwise, you have to do > it manually before or after you create your tag. Neither choice 'feels' quite right to m

Re: Tagging svn:externals

ernals to a specific revision, or tag the externals first and rewrite > your externals to point to the tagged externals. > > > > > On Wed, Feb 20, 2013 at 10:28 AM, C M wrote: > >> It seems that SVN does not tag svn:externals. >> >> We have defined a s

RE: Tagging svn:externals

@subversion.apache.org Subject: Tagging svn:externals It seems that SVN does not tag svn:externals. We have defined a structure such that child projects have link from a parent project. Parent project -> child project_1 -> child project_2 -&

Re: Tagging svn:externals

Externals are separate repositories by design. You should reference externals to a specific revision, or tag the externals first and rewrite your externals to point to the tagged externals. On Wed, Feb 20, 2013 at 10:28 AM, C M wrote: > It seems that SVN does not tag svn:externals. >

Tagging svn:externals

It seems that SVN does not tag svn:externals. We have defined a structure such that child projects have link from a parent project. Parent project -> child project_1 -> child project_2 -> child project_3 However, when you go to tag a rele

Resolved: svn:externals - svn: E200009: Targets must be working copy paths

so far! > > >> > > >> One last question on this topic. I want to pin the external > definition to a known revision using something this shortened command, but > it's not working. The "-r 109" being the revision I want to pin to. > > >> >

Re: svn:externals - svn: E200009: Targets must be working copy paths

gt; working. The "-r 109" being the revision I want to pin to. > >> > >> c:\Temp\800>svn propset svn:externals -r 109 . > >> > >> svn: E205000: Cannot specify revision for setting versioned property > >> 'svn:externals'

Re: svn:externals - svn: E200009: Targets must be working copy paths

>> One last question on this topic. I want to pin the external definition to a >> known revision using something this shortened command, but it's not working. >> The "-r 109" being the revision I want to pin to. >> >> c:\Temp\800>svn propset sv

Re: svn:externals - svn: E200009: Targets must be working copy paths

definition to a > known revision using something this shortened command, but it's not working. > The "-r 109" being the revision I want to pin to. > > c:\Temp\800>svn propset svn:externals -r 109 . > > svn: E205000: Cannot specify revision for setting versioned

Re: svn:externals - svn: E200009: Targets must be working copy paths

command, but it's not working. The "-r 109" being the revision I want to pin to. c:\Temp\800>svn propset svn:externals -r 109 . svn: E205000: Cannot specify revision for setting versioned property 'svn:externals' Andreas: I will provide feedback on the documentation shortl

RE: svn:externals - process question

As you've discovered, externals *always* pull in the HEAD revision unless you specifically add a revision number to the svn:externals property. Needless to say, "rogue" svn:externals are bad for build reproducibility and tagging. Options are: Audit the svn:externals (either

svn:externals - process question

Hello, My question is more process related with using svn:externals. In my testing, it seems that the svn:externals links are bi-directional. Changes are instantly propagated via the magic of svn:externals. 1. How do users preserve the integrity of a tag (which was created off a branch which

Re: svn:externals - svn: E200009: Targets must be working copy paths

property using the > > syntax below. > > > > > > c:\Temp\800>svn propset svn:externals "ver_1.0 > > svn://3.x.x.x/trunk/Customer1/system_800/ver_1.0" . > > property 'svn:externals' set on '.' > > > > This worked for the dir

Re: svn:externals - svn: E200009: Targets must be working copy paths

On Jan 30, 2013, at 14:14, C M wrote: > Thank you for the "teach a man to fish" approach. Though I didn't find the > documentation to be very clear, I was able to set the property using the > syntax below. > > > c:\Temp\800>svn propset svn:externals "

RE: svn:externals - svn: E200009: Targets must be working copy paths

Ryan, Thank you for the "teach a man to fish" approach. Though I didn't find the documentation to be very clear, I was able to set the property using the syntax below. c:\Temp\800>svn propset svn:externals "ver_1.0 svn://3.x.x.x/trunk/Customer1/system_800/ver_1.0" .

Re: svn:externals - svn: E200009: Targets must be working copy paths

On Jan 29, 2013, at 17:01, C M wrote: > I am attempting to set the svn:externals property via the command line, in > hopes of ultimately creating a batch file/script as we have a huge number of > externals to set. That dilemma aside, when I run the command, I get the > messag

svn:externals - svn: E200009: Targets must be working copy paths

Hello, I am attempting to set the svn:externals property via the command line, in hopes of ultimately creating a batch file/script as we have a huge number of externals to set. That dilemma aside, when I run the command, I get the message show below. My expectation is that this will set the prop

  1   2   3   >