updating a tag

[Dan Crosta <dc...@gmail.com>]

is there a simple idiom to use for updating a tag which already exists
to reflect the current contents of a working copy or of the /trunk
part of the repository? if you just reissue the svn cp command, it
will create a subdirectory of the tag directory (i found out the hard
way), and deleting and re-copying the tag causes 2 revisions rather
than 1. is there some idiom for ... basically updating a tag or branch
to the current contents of the trunk?

- d

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: updating a tag

[Andy Levy <an...@gmail.com>]

On 9/29/06, Dan Crosta <dc...@gmail.com> wrote:
> OK, that's what I figured... "floating label" sounds like about what I
> was looking for.
>
> Do people not generally use tags for maintenance to already-released
> versions? Or is that ordinarily done with branches? (I'm still a
> little unclear on the best practices and conventions surrounding those
> concepts)

What I've been done a few times is create a branch by copying the
tagged version.  Example:

We make a release and tag it as /tags/rev_100.
Development on trunk continues
Change comes in that has to be deployed without integrating current
trunk changes as they aren't finished
Copying /tags/rev_100 into a branch
Make changes in the branch
Release the branch (also tagging as /tags/rev_101)
Merge changes from branch to trunk as appropriate.

Other people frequently create a branch when they need to start doing
QA on the code, and then that branch is used for testing, debugging,
fixes, etc. and when deemed release-ready, a tag is made from there.
Changes in that branch are periodically merged back to trunk as
required.

Another option you may want to explore for your tag is to not make a
"eral" directory for the tag at all, but instead set svn:externals on
your tag directory and point it at a specific revision of your trunk.
As that tag moves, change which trunk rev it points at.

> For my stuff, I'll stick with the rm/cp method, or really just not
> tagging a version until I'm sure I'm done with it :-)
>
> Thanks,
> - d
>
> On 9/29/06, Reedick, Andrew <An...@bellsouth.com> wrote:
> > > -----Original Message-----
> > > From: Dan Crosta [mailto:dcrosta@gmail.com]
> > > Sent: Friday, September 29, 2006 3:45 PM
> > > To: users@subversion.tigris.org
> > > Subject: updating a tag
> > >
> > > is there a simple idiom to use for updating a tag which already exists
> > > to reflect the current contents of a working copy or of the /trunk
> > > part of the repository? if you just reissue the svn cp command, it
> > > will create a subdirectory of the tag directory (i found out the hard
> > > way), and deleting and re-copying the tag causes 2 revisions rather
> > > than 1. is there some idiom for ... basically updating a tag or branch
> > > to the current contents of the trunk?
> > >
> >
> > In theory, tags shouldn't be modified once created.
> >
> > If you need to update a tag, you can either treat like a branch and just
> > update it normally.  'svn co svn://.../some_tag, svn commit'
> >
> > Or you can recreate the tag, by deleting the tag and then creating a new
> > tag with the same name.  This is probably the better approach for your
> > case.  (Sounds like you want a 'floating label.')
> > If you need to reference the previous tags, then you can rename or move
> > the tag instead of deleting it.  Otherwise you'll need to read up on peg
> > branches to access previously deleted tags.
> >
> > If you don't want to delete/rm/mv the tag, then you'll need to merge the
> > trunk to the tag.  You'll need a script to automatically accept the
> > trunk's version in case of merge conflicts (not that there should be
> > any) by copying foo.java.right-r123 to foo.java.
> >
> >
> > *****
> >
> > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: updating a tag

["Reedick, Andrew" <An...@BellSouth.com>]

> -----Original Message-----
> From: Dan Crosta [mailto:dcrosta@gmail.com] 
> Sent: Friday, September 29, 2006 4:02 PM
> To: Reedick, Andrew
> Cc: users@subversion.tigris.org
> Subject: Re: updating a tag
> 
> OK, that's what I figured... "floating label" sounds like about what I
> was looking for.
> 
> Do people not generally use tags for maintenance to already-released
> versions? Or is that ordinarily done with branches? (I'm still a
> little unclear on the best practices and conventions surrounding those
> concepts)
> 
> For my stuff, I'll stick with the rm/cp method, or really just not
> tagging a version until I'm sure I'm done with it :-)
> 

Maintenance should be done on it's own branch.  The maintenance branch
should branch from the tag.

Working directly on the tag is bad because:
	- the tag is supposed to be a known baseline.  By developing in
the tag, anyone who tries to use the tag gets random code.  Random code
is bad, but only because customers don't like paying for random code,
which makes it difficult for your company to pay you.
	- if you start a patch in the tag, what do you do when a 2nd
more critical tag needs to go out first?
	- tags exist to help make branching or research easier.  If I
see tags/prod.1.0, I expect it to be 1.0, not 1.0 plus two maintenance
patches.
	- if you do update a tag, you're morally, legally, and ethically
obligated to warn everyone that if they checked out the tag previous to
your change, they need to run 'svn update', or worse, re-do and
re-deliver their work to pick your change.


You might want to look at the tools/contributed software and see about
limiting write access to the tags directory.


*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: updating a tag

[Dan Crosta <dc...@gmail.com>]

OK, that's what I figured... "floating label" sounds like about what I
was looking for.

Do people not generally use tags for maintenance to already-released
versions? Or is that ordinarily done with branches? (I'm still a
little unclear on the best practices and conventions surrounding those
concepts)

For my stuff, I'll stick with the rm/cp method, or really just not
tagging a version until I'm sure I'm done with it :-)

Thanks,
- d

On 9/29/06, Reedick, Andrew <An...@bellsouth.com> wrote:
> > -----Original Message-----
> > From: Dan Crosta [mailto:dcrosta@gmail.com]
> > Sent: Friday, September 29, 2006 3:45 PM
> > To: users@subversion.tigris.org
> > Subject: updating a tag
> >
> > is there a simple idiom to use for updating a tag which already exists
> > to reflect the current contents of a working copy or of the /trunk
> > part of the repository? if you just reissue the svn cp command, it
> > will create a subdirectory of the tag directory (i found out the hard
> > way), and deleting and re-copying the tag causes 2 revisions rather
> > than 1. is there some idiom for ... basically updating a tag or branch
> > to the current contents of the trunk?
> >
>
> In theory, tags shouldn't be modified once created.
>
> If you need to update a tag, you can either treat like a branch and just
> update it normally.  'svn co svn://.../some_tag, svn commit'
>
> Or you can recreate the tag, by deleting the tag and then creating a new
> tag with the same name.  This is probably the better approach for your
> case.  (Sounds like you want a 'floating label.')
> If you need to reference the previous tags, then you can rename or move
> the tag instead of deleting it.  Otherwise you'll need to read up on peg
> branches to access previously deleted tags.
>
> If you don't want to delete/rm/mv the tag, then you'll need to merge the
> trunk to the tag.  You'll need a script to automatically accept the
> trunk's version in case of merge conflicts (not that there should be
> any) by copying foo.java.right-r123 to foo.java.
>
>
> *****
>
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: updating a tag

["Reedick, Andrew" <An...@BellSouth.com>]

> -----Original Message-----
> From: Dan Crosta [mailto:dcrosta@gmail.com] 
> Sent: Friday, September 29, 2006 3:45 PM
> To: users@subversion.tigris.org
> Subject: updating a tag
> 
> is there a simple idiom to use for updating a tag which already exists
> to reflect the current contents of a working copy or of the /trunk
> part of the repository? if you just reissue the svn cp command, it
> will create a subdirectory of the tag directory (i found out the hard
> way), and deleting and re-copying the tag causes 2 revisions rather
> than 1. is there some idiom for ... basically updating a tag or branch
> to the current contents of the trunk?
> 

In theory, tags shouldn't be modified once created.

If you need to update a tag, you can either treat like a branch and just
update it normally.  'svn co svn://.../some_tag, svn commit'

Or you can recreate the tag, by deleting the tag and then creating a new
tag with the same name.  This is probably the better approach for your
case.  (Sounds like you want a 'floating label.')
If you need to reference the previous tags, then you can rename or move
the tag instead of deleting it.  Otherwise you'll need to read up on peg
branches to access previously deleted tags.

If you don't want to delete/rm/mv the tag, then you'll need to merge the
trunk to the tag.  You'll need a script to automatically accept the
trunk's version in case of merge conflicts (not that there should be
any) by copying foo.java.right-r123 to foo.java.


*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org