On 10/14/06, Kevin Greiner <greinerk@gmail.com> wrote:
> On 10/13/06, Les Mikesell <lesmikesell@gmail.com> wrote:
> > On Fri, 2006-10-13 at 11:43 -0700, Kenneth Porter wrote:
> >
> > > In other file-oriented systems, one checks out a previous snapshot of a
> > > part of the database using a timestamp. In Subversion, one grabs that
> same
> > > snapshot by revision number. I find the revision number more accurate
> and
> > > reliable.
> >
> > What does that mean in the context of putting unrelated projects
> > under the same repository? If you combine them, the repository
> > version number is going to change on projects where no change
> > took place. It probably doesn't really matter, since you normally
> > either check out the HEAD, not caring about the version number or
> > you create a tag if a specific version matters.
>
> Before we switched from VSS to svn, I too was a little worried about this
> "constantly changing" revision number. But in practice, it just isn't an
> issue. We have two repos: one for source code and one for binary files,
> typically use-case documents and such. We use specific revision numbers to
> refer to bug fixes, features, or patches in the source code and no one
> worries about contiguous revision numbers.
>
If your projects are not related to each other, don't put them in the
same repository.
I think part of the appeal of subversion is it's clean and relatively
simple interface (it is a version control tool so there is bound to be
SOME complexity).
The fact that subversion just versions directory trees and you can
interpret them however you like provides serious flexibility without a
lot of configuration. People are fairly used to organizing files by
directory and they often determine their directory hierarchy by
thinking of things like "Here's a folder for project A, here's a
folder for project B, etc.".
If you begin throwing in a special concept that is a "project", then
"named revisions" (a suggestion on another thread), and then allowing
an option to include a file's timestamp, etc, things begin to get
complicated and you start needing a full time admin just to sort it
all out (*cough* clearcase *cough*). Plus you have to start adding
more and more command to manage each new concept, making it even
harder to try to figure out what you want to do when you are lost.
Although I am not a Subversion dev, it seems to me that it was
designed to be powerful, useful, and flexible but still allow some guy
wanting to start an open source project to get up and running quickly.
Plus, a big part of the spirit of open source is choice...if you like
some other tool's way of doing something you SHOULD use that other
tool. I would personally like to see Subversion dominate the world,
but I understand that some people operate differently :-).
I believe I speak for most people on the list when I say that requests
of certain features that you feel would improve subversion are
welcome. However, using terms like "annoying" puts your email a bit
more on the insulting side. It is my understand that there was a lot
of time and thought put into this particular feature.
Finally, as an implementation issue I don't think you'd want the
individual timestamp feature. If you did that then every time someone
specified a date, Subversion would have to look through all of the
dates of all of the files, in addition to the revs. There might be
some possible optimizations but at some point you'll have to start
iterating through a bunch of files. That would mess up some of
Subversions "cheapness".
Just my thoughts.
Troy Curtis
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 16 05:57:19 2006