On Fri, Jul 3, 2009 at 9:44 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> 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.
The point I was making is that you have to perform N number of steps to
create a tag. I find it to be a bit tedious, even if you use a script.
However, you make a valid point about separate development cycles and
different milestones. But not all development cycles follow such an
independent structure. For example, the thing that determines when to tag a
library is the release/milestone of a product that uses it. This way,
projects and its dependencies are always at HEAD, and you make tags of them
on-demand as you go along. I've seen this used before and it isn't
unreasonable, especially if the libraries serve no other purpose than to
help your products. If the library was released to the world as middleware,
then things might be different.
> 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.
Again, good points I haven't thought of! This wasn't a very practical point
I was making, it was more of an edge-case. What would happen if a particular
library was deleted? Would I still be able to peg my externals to that
branch and check it out even though it does not exist anymore? I thought
this was what peg revisions were for.
>
>
>
>> 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.
Makes sense now. Thanks for explaining.
While this is a typical and favorable approach to development and release
cycles, it by no means is the only one (obviously). Point is, it can't
always be so easy. Take the on-demand tags approach. If a team is really
good and they use continuous integration, HEAD breaks less and
unit/integration testing happens at almost every submission. The way you
describe tags, they happen very frequently. Most companies tend to tag HEAD
only when they're approaching a release date or some other kind of milestone
for a product. When this happens, they may want to tag everything at once:
The product, and its dependencies. This would mark "The current state of the
repository when this product was released".
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367881
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 22:56:04 CEST