On Jun 29, 2006, at 21:39, Daniell, Casey B wrote:
>> Slight variation on the question: how would you make the site stay
>> at a
>> tagged version so untested changes could be committed, then tested
>> and
>> tagged when verified? I used to do this with CVS by rtagging the
>> tested
>> copy to float a known tag to that version, followed by an update
>> to the
>> working version, always using the same tag. That way it didn't
>> matter if
>> additional untested changes had been committed.
>> The script also floated a couple of previous-release tags
>> backwards so
>> you could always back out to earlier versions without having to track
>> any release numbers or tags.
>
> If anyone has suggestions on how to accomplish this I would love to
> hear
> them as well.
>
> We are currently managing 1000s of websites each with their own
> stylesheets/images ect. Having that team perform merges is not an
> option
> unless, so the idea of a floating tag similar to CVS, or CC is the
> most
> appealing. This way the customization guys and set a rdy_for_beta or
> rdy_for_prod type tag on their changes which is automatically push at
> specific times during the day via a svn update.
Tags in Subversion are not like tags in CVS. In CVS, you "apply a tag
to a file." A tag is a property of a file. (Or so I've heard. I never
used CVS.) In Subversion, you copy the trunk (or the branch you're
working on) to a directory called tags. And that's it. Usually you'd
give each tag a new version number or date. But you could certainly
have a tag called "ready for beta" and simply delete it and recreate
it when you want to update it.
Why is merging not an option?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 29 21:59:11 2006