> 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
