Robert Dailey wrote:
>
> 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.
Yes, a tag copy of a workspace will get the history of whatever is already
committed and identical in the repository. However, it is also possible to add
files and make other changes that haven't been committed anywhere else but this tag.
> 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.
I don't agree. For anything that uses libraries or subcomponents, I'd expect
the components to have a different development cycle than the main project (and
in fact to be used in different projects at different revisions) and nothing
built-in could have any way to predict what revision you would want for each
component. Early in development you might want to let everything float at HEAD,
but as soon as you want predictable results you'll want to have tagged each
component separately and pointed your externals to the tags.
> 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.
This doesn't make much sense to me either. Why would a repository containing a
component be any more or less likely to go away than the one holding your main
project? If you mean it might be controlled by someone else, point svnsync at
it and keep your own mirror that won't shut down unless you want it to.
>
> 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.
Start with a case where different teams are doing rapid changes on the
subcomponents you plan to use so you see the part that a version control system
needs to play. Assume that they will regularly break the HEAD of each component
and when you want your project to build you have to use the tested releases that
they have tagged for that purpose. Then just use the same approach even if you
are working alone: build/test/tag components first, then tie the externals to
the tested versions you want using the tag names to identify them.
--
Les Mikesell
lesmikesell_at_gmeil.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367820
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 16:45:06 CEST