Wow... I´m not alone.
It´s nice to see that soo many people have soo many different opinions. And
thanks to this, I have reached a veredict.
Looks like I´m not the only person with these strange feelings over the
one-and-only Repository. I guess that I´ll be using separate ones until I
can get the theory settled on my head. All that branching talk still makes
me dizzy. And I sure love a meaningful revision numer. Versions are another
thing alright, but revisions are important to me.
Since having a separate repository, as we all saw, has the advantage of
separating user access rights without the need for other programs, I saw it
as a healthy benefit. Besides the fact that the release number _is_
meaningful to some people, I have come to notice that this is yet another
recursive discussion, of the same kind of religious, sports, and C/C++
code style discussions.
I really like to stand for what I believe in, unless someone tells me
something that makes rethink and makes me understand things better. So
until that happens (until I read a decent book on branching and how to
become release-independent) I´ll create different repositories for my
projects. It´s the way I see it natural.
Thanks to all,
Rodrigo
P.S. Ben, is there a book teaching all these concepts (besides the
subversion one)?
Ben
Collins-Sussman Para: "Rule, Chris" <Chris.Rule@tbe.com>
<sussman@collab. cc: <ed.wittmann@fiserv.com>, <users@subversion.tigris.org>
net> Assunto: Re: Unclear: CVS and Subversion repository difference.
17/06/2005 15:59
On Jun 17, 2005, at 1:30 PM, Rule, Chris wrote:
>
> After reading all the posts on this subject and pondering, I think
> I've
> come to the conclusion that if revision numbers are going to be
> used in
> any communication with end users of the product, then the version
> releases has to include what revision it came from. The end users also
> assume (or have to be told) that revision numbers always increase.
> That
> way, if they see that a particular bug was fixed in revision 1234 but
> they have version 12 that came from revision 1200, then they
> automatically know they don't have the fix. Without the revision
> number
> association to the version, the note that a bug was fixed in
> revision x
> is meaningless to them.
>
This is an overly simplistic model. It assumes that the 'project' is
a single directory in the repository that progresses forever into the
future.
Most software uses branches and tags for release management. That
means software comes from long-lived branches, which are themselves
independent directories in the repository.
In other words, in the case of Subversion itself, it's meaningless
for someone to say, "I have revision 1200 of the svn client!"
Revision 1200 of what branch or path? Do you have (r1200, /trunk)?
Or perhaps (r1200, /branches/1.2.x)? Those are two completely
different things. If somebody asks me, "so, does that mean I have
the bug fixed by r1153?", there's no way for me to know. I don't
know which paths were changed in that revision, nor whether that
change was ported to my branch.
The revision number alone isn't enough to point to something in the
repository; you need a (revision, path) pair.
Again, take a look at how Subversion (and many other projects) do
their release management. Global numbers are used to specify
specific commits, but they are *not* used to indicate the "version"
of a piece of software. The *names* of the branches and tags are
used for that:
http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.4.1
---------------------------------------------------------------------
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
Received on Fri Jun 17 21:55:18 2005