On Wed, Feb 27, 2013 at 4:14 PM, BRM <bm_witness_at_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
lesmikesell_at_gmail.com
Received on 2013-02-27 23:30:57 CET