Robert Dailey wrote:
>
>
>> 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.
Maybe, but nothing can know which parts you want tagged with which names, so I
don't see much chance for additional automation.
> 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.
Usually the reason you have split into library components instead of just
embedding the source in the current project is because the components are used
by multiple projects, each of which is likely to have its own release cycle with
each project relying on previously tested functionality (i.e. not HEAD versions)
of components.
> 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.
Or if you have more than one product... As much as you try to keep them in sync
and using the latest changes it is rare to be able to - and the point of a
version control system is that you don't have to.
>>> 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.
Peg revisions would be able to access revisions that were deleted later, but if
you are tagging versions of components explicitly to identify the 'release
quality' versions that you should be using, it shouldn't be likely that anyone
would delete it.
>> 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).
It's the one that works in the worst case - where unpredictable changes are
being done at HEAD of any and all parts of the work. So it will work even if
you don't do that.
> Point is, it
> can't always be so easy.
Why not? Any time you tag something you can get it back at that state.
> 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.
I'm not sure things break less - it is just discovered and fixed sooner.
> 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.
I'd tag anything being tested. Or pretty much anything that I'd have any reason
to want to be able to reproduce. (This may partly be a bias from using CVS
where tags were the only reasonable way to identify a group of files, but it
works for svn and externals too).
> 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".
I don't think that's the case where independent development happens on the
components. You'd want a release branch to permit the trunk development to
continue for the next versions while you do final testing and bugfixes on the
branch - and at that point if not long before, you'd want the externals tied to
tested/tagged component versions. So basically nothing is at the 'repository
state' in the release.
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367891
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 23:51:38 CEST