> From: Les Mikesell <lesmikesell_at_gmail.com>
> To: BRM <bm_witness_at_yahoo.com>
> Cc: "users_at_subversion.apache.org" <users_at_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_witness_at_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_at_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
Received on 2013-02-27 23:14:54 CET