Re: Tagging svn:externals
From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com Cc: users@subversion.apache.org 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 bm_witn...@yahoo.com wrote: Not only does it solve the above, but it also enforces a discipline in how projects are updated to use newer versions of the tags; it also requires developers to be aware of which externals affect which projects - which, IMHO, is a good thing. Sure, it would be great if every component had well-tested, frozen APIs at release quality before any upper level project touched them. But on the other hand, APIs tend to miss the mark if they aren't 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 released already. Agreed, but the scenario is making a QA tag from trunk work. Most of these are dead ends if QA rejects them - that is, with rare exceptions anything that needs to be fixed would be fixed on the trunk and a new QA tag made. My thinking is that there really should be an intermediate QA branch where the externals are pinned but it seems like a big waste when there will never be any other change on that branch. Plus, we are increasingly automating this with a jenkins 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:externals and always be ready for QA. And QA would have to have a similar process specified for any updates they do. Ultimately nothing I/we say can do anything but help you define the process and how it needs to work for you and your team(s). And if I don't need to modify an external during development, then it never moves from the release the project used. Sure, many/most stay tied to tagged component releases even during trunk work on the upper level projects, but it is still a common scenario to need to make changes in both simultaneously. I don't think that would be an issue. Again, it's how you define the process for your developers/QA Testers/QA Fixers. Now, in a sense you're looking to do that automatically as you make a release of the project you're working on. But it really all comes down to the release process, the tools you use for release, and their capabilities. I don't think you can do it automatically unless you pin to peg revisions in the same repository. How would anything automatic find the right component tag or deal with concurrent changes in a separate repo? By automation I mean having scripts setup that can update the pegs revisions or tags automatically. It can be relatively easy to do (depending on the scripting language) but will be very specific to your repository use. The script would just need to be able to parse svn pget svn:externals and svn info on the various externals. I'm not saying its the full solution - or even the right one; just that that is how you are seeming to want to go. Personally I think the right solution is defining your processes for everyone. Keep it easy to do, but make sure everyone understands what they are suppose to do. Ben
Is SVN-1.6.12 compatible with Rhel6u2?
Hi, I just stood up an exact replica of a collabnet subversion server(*version=1.6.12 and configured to run as apache subversion*). I have enabled ssl(*using an existing ssl cert from the production box*). I am able to access the server using my browsers or svn clients like smartSVN or TortoiseSVN. But, when I hit refresh(F5) on the repo-browser of TortoiseSVN client, I see an error like this: *Server sent unexpected return value (400 Bad Request) in response to OPTIONS request for https://xx.xx.xx.xx/xx/ad/test-repo1/branches/newname*; I am not able to reproduce this error on the production server. The only difference between the production and this backup is: (1) Production is on a Rhel5u6 and the backup is on Rhel6u2. I was not able to find any OS compatibility document for svn-1.6.12 (2) Production has a valid ssl certificate. Backup is using the ssl certificate from production. These are the logs I see: *ssl_request_log* *[25/Feb/2013:07:53:42 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA OPTIONS /xx/ad/test-repo1/branches/newname HTTP/1.1 300* *ssl_access_log* *xx.xx.xx.xx - - [25/Feb/2013:07:53:42 -0500] OPTIONS /xx/ad/test-repo1/branches/newname HTTP/1.1 400 300* *ssl_error_log* *[Mon Feb 25 07:53:42 2013] [error] [client xx.xx.xx.xx] request failed: error reading the headers* * * after this failure, I get subsequent failure log like the following until I restart the client: *ssl_request_log* [*25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA OPTIONS /xx/ad/test-repo1/trunk HTTP/1.1 401* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA OPTIONS /xx/ad/test-repo1/trunk HTTP/1.1 196* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 702* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 414* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1 465* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 702* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 414* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1 465* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 702* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 465* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1 1329* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA REPORT /xx/ad/test-repo1/trunk HTTP/1.1 112* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 702* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 465* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1 430* *[25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1 1298* *ssl_access_log* *xx.xx.xx.xx - - [25/Feb/2013:09:21:46 -0500] OPTIONS /xx/ad/test-repo1/trunk HTTP/1.1 401 401* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] OPTIONS /xx/ad/test-repo1/trunk HTTP/1.1 200 196* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 207 702* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 207 414* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1 207 465* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 207 702* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 207 414* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1 207 465* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 207 702* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 207 465* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1 207 1329* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] REPORT /xx/ad/test-repo1/trunk HTTP/1.1 200 112* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 207 702* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 207 465* *xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1 207 430*
RE: Merge, reintegrate, and merge with tree conflicts
So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. You can keep the feature branch alive by doing a record only merge on the trunk of the revision which your integrate merge was committed as. BOb On Feb 22, 2013, at 7:22 PM, Matthew Pounsett m...@conundrum.com wrote: On 2013/02/22, at 14:15, James Hanley wrote: We are seeing merge tree conflicts where I believe svn is not working as expected. I'm not entirely sure if this is due to a lack of understanding for proper use on our part, but it was my understanding that reintegrate was to be used when pulling changes from a branch and pushing them into the copied from branch. I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way: cd branches svn cp ^/trunk ./mybranch cd mybranch mkdir foo svn add foo svn commit -m added foo to mybranch cd ../../trunk svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch svn merge ^/trunk As soon as the --reintegrate is done, ^/branches/mybranch is dead. [1] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox /%3C01A9EBD6-CE2D-4565-833D-2252CE2E5B71%40conundrum.com%3E [2] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox /%3C20130207150922.GC28403%40ted.stsp.name%3E
RE: Merge, reintegrate, and merge with tree conflicts
So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. You can keep the feature branch alive by doing a record only merge on the trunk of the revision which your integrate merge was committed as. Sorry, this should say: You can keep the feature branch alive by doing a record only merge on the branch from trunk of the revision which your integrate merge was committed as. BOb BOb On Feb 22, 2013, at 7:22 PM, Matthew Pounsett m...@conundrum.com wrote: On 2013/02/22, at 14:15, James Hanley wrote: We are seeing merge tree conflicts where I believe svn is not working as expected. I'm not entirely sure if this is due to a lack of understanding for proper use on our part, but it was my understanding that reintegrate was to be used when pulling changes from a branch and pushing them into the copied from branch. I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way: cd branches svn cp ^/trunk ./mybranch cd mybranch mkdir foo svn add foo svn commit -m added foo to mybranch cd ../../trunk svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch svn merge ^/trunk As soon as the --reintegrate is done, ^/branches/mybranch is dead. [1] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb ox /%3C01A9EBD6-CE2D-4565-833D- 2252CE2E5B71%40conundrum.com%3E [2] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb ox /%3C20130207150922.GC28403%40ted.stsp.name%3E
Re: Is SVN-1.6.12 compatible with Rhel6u2?
On Tue, Feb 26, 2013 at 11:35 AM, Kriparam Faraday kripa...@gmail.com wrote: Hi, I just stood up an exact replica of a collabnet subversion server(version=1.6.12 and configured to run as apache subversion). I have enabled ssl(using an existing ssl cert from the production box). I am able to access the server using my browsers or svn clients like smartSVN or TortoiseSVN. But, when I hit refresh(F5) on the repo-browser of TortoiseSVN client, I see an error like this: Server sent unexpected return value (400 Bad Request) in response to OPTIONS request for https://xx.xx.xx.xx/xx/ad/test-repo1/branches/newname; I am not able to reproduce this error on the production server. The only difference between the production and this backup is: (1) Production is on a Rhel5u6 and the backup is on Rhel6u2. I was not able to find any OS compatibility document for svn-1.6.12 RedHat's copy of subversion is out of date on RHEL. You're quite welcome to my updated versions published at repoforge in the extras repositories, or my tools for building Subversoin 1.6.20 and 1.7.8 RPM's available at: https://github.com/nkadel/subversion-1.6.20-srpm/ https://github.com/nkadel/subversion-1.7.8-srpm/ (2) Production has a valid ssl certificate. Backup is using the ssl certificate from production. These are the logs I see: ssl_request_log [25/Feb/2013:07:53:42 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA OPTIONS /xx/ad/test-repo1/branches/newname HTTP/1.1 300 ssl_access_log xx.xx.xx.xx - - [25/Feb/2013:07:53:42 -0500] OPTIONS /xx/ad/test-repo1/branches/newname HTTP/1.1 400 300 ssl_error_log [Mon Feb 25 07:53:42 2013] [error] [client xx.xx.xx.xx] request failed: error reading the headers after this failure, I get subsequent failure log like the following until I restart the client: ssl_request_log [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA OPTIONS /xx/ad/test-repo1/trunk HTTP/1.1 401 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA OPTIONS /xx/ad/test-repo1/trunk HTTP/1.1 196 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 702 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 414 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1 465 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 702 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 414 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1 465 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 702 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 465 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1 1329 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA REPORT /xx/ad/test-repo1/trunk HTTP/1.1 112 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 702 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 465 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1 430 [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA PROPFIND /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1 1298 ssl_access_log xx.xx.xx.xx - - [25/Feb/2013:09:21:46 -0500] OPTIONS /xx/ad/test-repo1/trunk HTTP/1.1 401 401 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] OPTIONS /xx/ad/test-repo1/trunk HTTP/1.1 200 196 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 207 702 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 207 414 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1 207 465 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 207 702 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 207 414 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1 207 465 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/trunk HTTP/1.1 207 702 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1 207 465 xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] PROPFIND /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1 207 1329 xx.xx.xx.xx -
Re: Tagging svn:externals
From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com Cc: users@subversion.apache.org 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 bm_witn...@yahoo.com wrote: Agreed, but the scenario is making a QA tag from trunk work. Most of these are dead ends if QA rejects them - that is, with rare exceptions anything that needs to be fixed would be fixed on the trunk and a new QA tag made. My thinking is that there really should be an intermediate QA branch where the externals are pinned but it seems like a big waste when there will never be any other change on that branch. Plus, we are increasingly automating this with a jenkins 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:externals and always be ready for QA. And QA would have to have a similar process specified for any updates they do. We do development on trunk. It just seems like the logical place... That's one of two recognized methods - trunk is prestine or trunk is dirty. For trunk is dirty there is no guarantee that any given revision is useable. For trunk is prestine development methodology says any given revision must be useable. Both are enforced by project preferences and policy. Ultimately nothing I/we say can do anything but help you define the process and how it needs to work for you and your team(s). On the other hand, it would be helpful if there were a best practices document on how best deal with the inherent conflict between the concepts of concurrent development on trunk, and the conventions of (a) externals always being pegged in tags and (b) no changes _after_ tagging. The only clean approach looks to me like making a branch whose only purpose is to be a place to make the change to the external references - but that also seem like a lot of extra effort and clutter in the repository for that operation. But, if that is what it takes, it would be easier to convince developers to do it that way if there were some official document describing it. From what I can tell - and others can verify this - Subversion tries to allow the developers to choose the development model that best fits their needs. As such, such a document would have to be generated for numerous development models. That said, I think what you're looking to do makes more sense in a trunk is prestine model than a trunk is dirty model. My own repositories use the trunk is prestine model. Sure, many/most stay tied to tagged component releases even during trunk work on the upper level projects, but it is still a common scenario to need to make changes in both simultaneously. I don't think that would be an issue. Again, it's how you define the process for your developers/QA Testers/QA Fixers. I'm just saying it would be nicer if every user didn't have to make up a different workflow process to accomplish the same thing... I think it's a matter of finding what works best for your team. Good tools, like Subversion, make it easy to customize your workflow for what you need to do. Some functions fit certain workflows better than others; but they are available. Now, in a sense you're looking to do that automatically as you make a release of the project you're working on. But it really all comes down to the release process, the tools you use for release, and their capabilities. I don't think you can do it automatically unless you pin to peg revisions in the same repository. How would anything automatic find the right component tag or deal with concurrent changes in a separate repo? By automation I mean having scripts setup that can update the pegs revisions or tags automatically. It can be relatively easy to do (depending on the scripting language) but will be very specific to your repository use. How can a script possibly know the correct tag for an external target which is currently pointing at the trunk in a repository that permits concurrent operations? In my example, it would simply update, then 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. The script would just need to be able to parse svn pget svn:externals and svn info on the various externals. I'm not saying its the full solution - or even the right one; just that that is how you are seeming to want to go. Personally I think the right solution is defining your processes for everyone. Keep it easy to do, but make sure everyone understands what they are suppose to do. That is a lot easier if you can make that solution avoid extra work
Re: Tagging svn:externals
On Tue, Feb 26, 2013 at 4:29 PM, BRM bm_witn...@yahoo.com wrote: How can a script possibly know the correct tag for an external target which is currently pointing at the trunk in a repository that permits concurrent operations? In my example, it would simply update, then 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 previously tagged component versions. Without forcing that to be committed to the trunk or encouraging copying to tags from a workspace that doesn't match any trunk commit. As you can probably guess, I'm a big fan of trunk is prestine; mostly because I'm a big fan of doing things in a very structured, deterministic way. I'm a fan of not cluttering the repository with unnecessary branches, and in making it simple for everyone involved to pick up each others' changes sooner rather than later. And in getting determinism through consistent tagging, and only using release tags where determinism matters. You seem to be wanting that determinism. It'd be interesting to see what a big fan of trunk is dirty would say for how to do the same thing; but somehow I suspect you can't do it while maintaining the determinism. The question is just about what would be considered best practice in where/how that change between an unpinned external and one pointing to a separately released tagged version should happen. I don't think whether the ongoing work is a branch or trunk matters. As long there is continuing (possibly concurrent) development in the location before you make the tag, you have to decide whether to (a) make another branch just to hold this change, (b) commit the change back to the development location, then undo it after the tag copy, (c) copy to the tag from a modified working copy, or (d) change it in the tag, violating the 'tags never change' convention? I personally don't like the idea of tagging from a modified working copy because of the possibility that other changes with no history can accidentally be brought along. -- Les Mikesell lesmikes...@gmail.com
