On Sun, 2006-11-19 at 01:06, Alan Barrett wrote:
> > Is there a reason not to?
>
> Tagging is extra effort, extra entries in the logs, extra directories
> in the view presented by a repository browser. Why use tags (which are
> really copies in subversion) if you can get away with revision numbers?
Aren't revision numbers also copies in subversion? The part I'm
having trouble with is how to permit ongoing concurrent development
in the repository beyond the workspace copy containing the
state you want to tag. Maybe I've taken the CVS arguments for
the usefulness of this feature too seriously. It has been rare
in practice except for web content where a marketing group
changes portions in a way that does not need much coordination
with the functional parts, but still I don't ever want to
tell someone they can't commit new work or that they have
to make a branch because the system needs it for concurrent
work.
> > Sorry to drag it out then, but coming from CVS where tagging is the
> > only way to represent a known state [...]
>
> With CVS, I usually used "-r ${branch} -D ${date_time}" to represent
> a candidate for testing. I am aware that that that checkouts with
> the -D flag don't always do the right thing in CVS, especially in
> conjunction with vendor branches, but they always worked well enough for
> me.
This has the same issue in that the repository branch
may have had additional commits beyond the state of the
workspace that you want to duplicate for the test. That
is, you want to pick up the commits from that workspace
but no others beyond it's last update. Maybe my perspective
is warped from dealing with developers in a different country
adding "tomorrow's" work overlapping with the time you might
be running tests against today's changes by a different group.
If you are a single developer or a small local group you might
never have a concurrency problem but it seems like something
a version control system should handle.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Nov 19 21:47:13 2006