subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BRM <bm_witn...@yahoo.com>
Subject Re: Tagging svn:externals
Date Fri, 22 Feb 2013 15:02:44 GMT
> From: Les Mikesell <lesmikesell@gmail.com>

> To: BRM <bm_witness@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_witness@yahoo.com> wrote:
>> 
>>>  On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer 
> <Bob.Archer@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


Mime
View raw message