I'd like to add to that. Some people may think that it's terrible to be
able to modify a tag, but the great thing about Subversion's model is
that sometimes you do need to modify a tag--such as when a build break
was fixed, or to account for code generated in a build that you want to
commit.
I don't see how tags as first-class objects can be easy to use in the
first case--moving the tags around gets tricky especially if there are
overlapping commits. And in the second case, they seem unworkable--your
generated code does not necessarily belong back in the trunk, unless you
want your build process to work that way.
Subversion easily and cleanly accommodates both use cases. I think it's
a huge strength rather than the hack some people believe it to be.
--Todd
> I'm going to have to jump in here and defend Subversion. You can't
> call something a "design error" without a lot of justification. :-)
> Implementing tags as copies works great in Subversion. Copies take up
> virtually no space in the repository unless you start modifying them,
> and then they take up as much space as your modifications. So what is
> your objection to tags as copies?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-25 00:19:31 CEST