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: Wednesday, February 27, 2013 5:49 PM Subject: Re: Tagging svn:externals On Wed, Feb 27, 2013 at 4:44 PM, BRM bm_witn...@yahoo.com 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 to pick up. How you change the externals in the process I'm not sure; but it would at least give you a trackable repository that would mimick a modified working copy. Otherwise I think you're out of luck if you don't want to (i) commit to trunk, or (ii) create a branch, but still want to track it in the repository somehow. 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 working copy is extremely easy: $ svn copy . ^/path/to/tag/or/branch It's a first-class operation in subversion. Likewise, you can: $ svn copy . ^/path/to/tag/or/branch $ svn switch ^/path/to/tag/or/branch ...make modifications here.. $ svn commit Ben
Re: Tagging svn:externals
On Thu, Feb 28, 2013 at 3:34 PM, BRM bm_witn...@yahoo.com 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 working copy is extremely easy: $ svn copy . ^/path/to/tag/or/branch It's a first-class operation in subversion. Yes, that does work and seems like a reasonable thing if no change other than the externals is done. But if you aren't careful, you can easily add items that don't exist anywhere else. And you have to revert your change before continuing commits to trunk. Likewise, you can: $ svn copy . ^/path/to/tag/or/branch $ svn switch ^/path/to/tag/or/branch ...make modifications here.. $ svn commit Likewise, something that works, but if it is a tag you are violating the convention of not committing changes to tags. Leaving the question of which of these would be considered a 'best practice'. -- Les Mikesell lesmikes...@gmail.com
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: Thursday, February 28, 2013 5:29 PM Subject: Re: Tagging svn:externals On Thu, Feb 28, 2013 at 3:34 PM, BRM bm_witn...@yahoo.com 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 working copy is extremely easy: $ svn copy . ^/path/to/tag/or/branch It's a first-class operation in subversion. Yes, that does work and seems like a reasonable thing if no change other than the externals is done. But if you aren't careful, you can easily add items that don't exist anywhere else. And you have to revert your change before continuing commits to trunk. Likewise, you can: $ svn copy . ^/path/to/tag/or/branch $ svn switch ^/path/to/tag/or/branch ...make modifications here.. $ svn commit Likewise, something that works, but if it is a tag you are violating the convention of not committing changes to tags. Leaving the question of which of these would be considered a 'best practice'. You could always use a slightly modified structure for your projects: trunk tags branches qa Your tagging for QA could be done to the qa tree, and then you are no longer breaking the rule of not modifying tags. You also enforce that actual tags (under the tags tree) must from from the qa tree; this can be hard-enforced with a pre-commit hook, or soft enforced in project policy alone. Ben
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 6:12 PM Subject: 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. 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 without committing. 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. So if you don't need a branch, delete it. Personally I do an svn del on any branch that I no longer need - whether abandoned or reintegrated. This keeps the branch list short, and (more importantly) relevant. The nice thing with Subversion is that you can still get to all those old branches. 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. Let me propose this: For QA, let them do a simple modified working copy to get the svn:externals where you want them; but then they are not allowed to commit or make other changes. You'll have to decide how you want bug fixes to be interacted with; but that will provide what you've been describing. For developers, they can do whatever you like. Again, as I've noted it comes down to what policies you want your team to follow. Ben
Re: Tagging svn:externals
On Wed, Feb 27, 2013 at 4:14 PM, BRM bm_witn...@yahoo.com wrote: 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. 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 without committing. Everything is built by jenkins and has to come from the repository. Things in uncommitted workspaces aren't necessarily repeatable. 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. So if you don't need a branch, delete it. Personally I do an svn del on any branch that I no longer need - whether abandoned or reintegrated. This keeps the branch list short, and (more importantly) relevant. The nice thing with Subversion is that you can still get to all those old branches. That's a not-so-nice thing too. The repo is growing at about 10 gigs/year. While I realize that extra tags/branches are a very small part of the problem I don't want to encourage unnecessary clutter until there is some reasonable way to reorganize and actually remove things. 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. Let me propose this: For QA, let them do a simple modified working copy to get the svn:externals where you want them; but then they are not allowed to commit or make other changes. Won't work - it has to be committed somewhere or it won't be built. -- Les Mikesell lesmikes...@gmail.com
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: Wednesday, February 27, 2013 5:30 PM Subject: Re: Tagging svn:externals On Wed, Feb 27, 2013 at 4:14 PM, BRM bm_witn...@yahoo.com wrote: 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. 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 without committing. Everything is built by jenkins and has to come from the repository. Things in uncommitted workspaces aren't necessarily repeatable. ,,, Let me propose this: For QA, let them do a simple modified working copy to get the svn:externals where you want them; but then they are not allowed to commit or make other changes. 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 to pick up. How you change the externals in the process I'm not sure; but it would at least give you a trackable repository that would mimick a modified working copy. Otherwise I think you're out of luck if you don't want to (i) commit to trunk, or (ii) create a branch, but still want to track it in the repository somehow. Ben [1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
Re: Tagging svn:externals
On Wed, Feb 27, 2013 at 4:44 PM, BRM bm_witn...@yahoo.com 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 to pick up. How you change the externals in the process I'm not sure; but it would at least give you a trackable repository that would mimick a modified working copy. Otherwise I think you're out of luck if you don't want to (i) commit to trunk, or (ii) create a branch, but still want to track it in the repository somehow. 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. -- Les Mikesell lesmikes...@gmail.com
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
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
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: Thursday, February 21, 2013 11:09 AM Subject: Re: Tagging svn:externals On Thu, Feb 21, 2013 at 9:42 AM, BRM bm_witn...@yahoo.com wrote: On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer bob.arc...@amsi.com 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 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 components. And if you change it in the tag you are breaking the convention that you don't change tags. And if you copy the working copy to a tag you might get other changes in the tag that weren't committed anywhere else. Is there a 'best practice' consensus for this step? While I do agree, I think the simple solution is to generally just use tagged externals to start with, and then switch them to trunk or a branch when you need to work on them from that project. That makes sense when you aren't concurrently working on a component and the project using it. But that is the problem case - and common. 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. And if I don't need to modify an external during development, then it never moves from the release the project used. 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. $0.02 Ben
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. 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. 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? -- Les Mikesell lesmikes...@gmail.com
Re: Tagging svn:externals
On Thu, Feb 21, 2013 at 9:42 AM, BRM bm_witn...@yahoo.com wrote: On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer bob.arc...@amsi.com 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 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 components. And if you change it in the tag you are breaking the convention that you don't change tags. And if you copy the working copy to a tag you might get other changes in the tag that weren't committed anywhere else.Is there a 'best practice' consensus for this step? While I do agree, I think the simple solution is to generally just use tagged externals to start with, and then switch them to trunk or a branch when you need to work on them from that project. That makes sense when you aren't concurrently working on a component and the project using it. But that is the problem case - and common. 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 -- Les Mikesell lesmikes...@gmail.com
Re: Tagging svn:externals
Les Mikesell lesmikes...@gmail.com 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 components. And if you change it in the tag you are breaking the convention that you don't change tags. And if you copy the working copy to a tag you might get other changes in the tag that weren't committed anywhere else.Is there a 'best practice' consensus for this step? You could write a script using svnmucc so that the copy and the property change happen in the same commit. We do something like that when tagging Subversion, we edit a header when we make a tag: $ svn log -vq --stop-on-copy http://svn.apache.org/repos/asf/subversion/tags/1.7.8 r1419826 | breser | 2012-12-10 22:01:28 + (Mon, 10 Dec 2012) Changed paths: A /subversion/tags/1.7.8 (from /subversion/branches/1.7.x:1419691) M /subversion/tags/1.7.8/subversion/include/svn_version.h -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
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 trunk that expects the externals to also follow trunk components. And if you change it in the tag you are breaking the convention that you don't change tags. And if you copy the working copy to a tag you might get other changes in the tag that weren't committed anywhere else.Is there a 'best practice' consensus for this step? You could write a script using svnmucc so that the copy and the property change happen in the same commit. We do something like that when tagging Subversion, we edit a header when we make a tag: I thought that's what the svncopy.pl script is supposed to do. http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svncopy/svncopy.README
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 release for a child, there's nothing in the /tags/Rel_X as I would normally expect. What's going on here? Amad
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 cmanalys...@gmail.com wrote: 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 release for a child, there's nothing in the /tags/Rel_X as I would normally expect. What's going on here? Amad -- Connect with us on twitter http://twitter.com/cardinalpath, google+https://plus.google.com/108076800625872227241/posts , facebook http://www.facebook.com/CardinalPath, or linkedinhttp://www.linkedin.com/company/cardinal-path . Catch our next training in St Louis Feb 25 - Mar 1http://training.cardinalpath.com/google-adwords-analytics/saint-louis/?utm_campaign=cp-cptutm_source=sig-referralutm_medium=emailutm_content=stlouis-2013-02-25 , Vancouver Mar 4 - 8http://training.cardinalpath.com/google-adwords-analytics/vancouver/?utm_campaign=cp-cptutm_source=sig-referralutm_medium=emailutm_content=vancouver-2013-03-04 , New York City Mar 11 - 15 http://goo.gl/y4Ojj, Atlanta Apr 10 - 12http://goo.gl/oJGyd or See All http://cpath.it/Jkrs3s. This email, including any attachments, is for the sole use of the intended recipient and may contain confidential information. If you are not the intended recipient, please immediately notify us by reply email or by telephone, delete this email and destroy any copies. Thank you.
RE: Tagging svn:externals
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. From: C M [mailto:cmanalys...@gmail.com] Sent: Wednesday, February 20, 2013 12:29 PM To: users@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 - child project_3 However, when you go to tag a release for a child, there's nothing in the /tags/Rel_X as I would normally expect. What's going on here? Amad
Re: Tagging svn:externals
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. On Wed, Feb 20, 2013 at 11:42 AM, Geoff Hoffman ghoff...@cardinalpath.comwrote: 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 cmanalys...@gmail.com wrote: 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 release for a child, there's nothing in the /tags/Rel_X as I would normally expect. What's going on here? Amad Connect with us on twitter http://twitter.com/cardinalpath, google+https://plus.google.com/108076800625872227241/posts , facebook http://www.facebook.com/CardinalPath,** or linkedinhttp://www.linkedin.com/company/cardinal-path . Catch our next training in St Louis Feb 25 - Mar 1http://training.cardinalpath.com/google-adwords-analytics/saint-louis/?utm_campaign=cp-cptutm_source=sig-referralutm_medium=emailutm_content=stlouis-2013-02-25 , Vancouver Mar 4 - 8http://training.cardinalpath.com/google-adwords-analytics/vancouver/?utm_campaign=cp-cptutm_source=sig-referralutm_medium=emailutm_content=vancouver-2013-03-04 , New York City Mar 11 - 15 http://goo.gl/y4Ojj, Atlanta Apr 10 - 12http://goo.gl/oJGyd or See All http://cpath.it/Jkrs3s. This email, including any attachments, is for the sole use of the intended recipient and may contain confidential information. If you are not the intended recipient, please immediately notify us by reply email or by telephone, delete this email and destroy any copies. Thank you.
Re: Tagging svn:externals
On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer bob.arc...@amsi.com 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 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 components. And if you change it in the tag you are breaking the convention that you don't change tags. And if you copy the working copy to a tag you might get other changes in the tag that weren't committed anywhere else.Is there a 'best practice' consensus for this step? -- Les Mikesell lesmikes...@gmail.com
Re: Tagging svn:externals
On Wed, Feb 20, 2013 at 11:58 AM, C M cmanalys...@gmail.com 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 source. -- Les Mikesell lesmikes...@gmail.com
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 lesmikes...@gmail.comwrote: On Wed, Feb 20, 2013 at 11:58 AM, C M cmanalys...@gmail.com 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 source. -- Les Mikesell lesmikes...@gmail.com
Re: Tagging svn:externals
On Wed, Feb 20, 2013 at 12:30 PM, C M cmanalys...@gmail.com 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 has external references, you should get the same structure re-created when you check it out. That is, it copies the reference only. The usual issue with this is that if the externals point to trunk versions without peg revisions, the subsequent checkout may pull in components that are newer than what you tagged. But it sounds like you have some other issue or misunderstanding. -- Les Mikesell lesmikes...@gmail.com
