Resending this, the mailing list said it was rejected....
On Fri, Jul 3, 2009 at 8:37 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> Robert Dailey wrote:
>
>>
>>
>> On Fri, Jul 3, 2009 at 4:14 AM, Bolstridge, Andrew <
>> andy.bolstridge_at_intergraph.com <mailto:andy.bolstridge_at_intergraph.com>>
>> wrote:
>>
>> I’d do the tagging the way it “should” be – take the current
>> revision number, and remember it.
>>
>> If you ever want to get the current state of your release, do a
>> checkout using that revnum. Really simple.
>>
>>
>> But that's what tags do. They give a name to that revision number. It's a
>> lot better than writing it down on paper somewhere. This still doesn't
>> address the issue of tagging multiple branches. If dependencies are in
>> different branches, those branches must be tagged at the same time the
>> project is. You can't do this with one tag operation.
>> Tags in Subversion, from my investigation need 2 major improvements. Tags
>> in Subversion shouldn't be simple "copies". I should be able to only tag a
>> specific part of a hierarchy in the repository, much like you would use
>> sparse checkouts. For example, in the root of the repository you may have 5
>> directories: Project1, Project2, Project3, Library1, Library2. I should be
>> able to only tag Project1, Library1, and Library2. Project2 and 3 would not
>> be in the tag (This would be a sparse tag).
>>
>
> I haven't tried, but don't you get this if you copy a workspace built that
> way to a tag (with all the downsides of doing that, like not necessarily
> having any other history of files there)?
For a tag, history seems pretty important. Granted, the history would still
be there with a copy I believe. While you can always use external tools to
make this possible, that has the disadvantage of making SVN less useful out
of the box. I hear a lot of arguments for Perforce at companies I've worked
for just because Perforce supports it out of the box. For companies and open
source projects this actually means a lot.
>
> Secondly, tag operations should allow a user to select multiple branches.
>> A tag would then contain multiple, distant branches this way.
>>
>
> Why? Externals are a better way to get sub-components, but they should
> point to tagged copies.
Externals have a few big problems:
They require you to modify them before you create the tag to explicitly set
the revision of the external the tag is intended to reference. If you don't
do this, the tag will always point to HEAD. Which is why it is important to
set -r1234 before you create the tag. Again, this requires extra steps and
should be built-in.
If the external isn't relative, you run the possibility of that external not
being valid anymore if the server it is pointing to shuts down or no longer
is available to you. This is why having the copy in your repository is VERY
important.
>
>
> Given the implementation of Subversion, I'm not sure if this is possible,
>> but it would be a great thing to have.
>>
>
> The problem here is not so much not being able to create the tags you want
> but the time that you let the libraries (externals) float pointing at their
> HEAD revisions. A cleaner approach is to tag the sub-components at
> 'release-tested' points, make a release branch of the main code where you
> peg the externals to the appropriate tags, then create QA and release tags
> from the branch. This way additional changes can be made anywhere in the
> project or library trunks without affecting your current builds and release
> and the final tags are created atomically.
I'm not sure I understand what you're saying.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367813
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 16:01:16 CEST