Rapidly-changing revision number (was: First-time user (Windows platform))

[Kenneth Porter <sh...@sewingwitch.com>]

--On Friday, October 13, 2006 1:12 PM -0500 Ted Dennison 
<de...@ssd.fsi.com> wrote:

> Wasn't there recently an argument here for multiple repositories, on the
> basis that working with revisions can get annoying when the entire
> repository (and thus every "project" in it) gets a new revision every
> time something changes?

"Annoying"? That's hardly a good technical argument. (I realize you're 
quoting a previous thread and that it's not your argument.)

The revision is not unlike a timestamp. Would one complain that every 
check-in has a unique timestamp?

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.

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

Re: Rapidly-changing revision number

[Talden <ta...@gmail.com>]

Frank Gruman
> > My preference and the way I have my repos set up - each project has it's
> > own repository.  If I want to do some sort of work/testing/anything to
> > one, I don't have to kill the whole development process to do it.  From
> > the developer perspective, they know that their code is segregated by
> > project.  They don't know or care that there are one or many repositories.

Kenneth Porter
> Setting up projects in their own repositories makes sense if they're
> independent. If one project depends on another, or they share a common
> library project, then a shared repository insures that changes in the
> depended-upon project that break the dependent project can be identified
> and rolled back.

I guess here's where the 'term' project breaks down.

If you have two products (that is, artifacts that are delivered on
different schedules whether they are bundled together or not) then
they should have separate repositories.

If two of these 'products' have a shared library (a sub-product) then
it too should have it's own repository, and it's own release process.
Why have Product A dependant on the progress of Product B just because
they share a library - have releases of the library and treat it as a
product from its team.  Product A shouldn't have to be developed
against the moving target of its dependancy due to the outside
influence of Product B.

That said, the NEED to place them in separate repositories is
absolutely only important to you if the repository revision number has
some relevence to your development process other than the
identification of the repository at a point in time (and the effect of
a commit rN-1:rN).

I would absolutely recommend separate repositories if there really are
multiple teams working on these projects and subprojects all at once
(just due to the commit activity levels)...

--
Talden

>
> Alas, the real world is full of coupling between projects, so one is
> tempted to put all projects in one repo. But separate repos tend to be
> easier to admin. So it depends on just how much coupling there is between
> the projects.
>
> If you've got good interface boundaries that can be represented by a repo
> tag, then separate repos are tenable, as changes to the library are
> captured in tags and the dependent project can specify the tag(s) that it's
> compatible with.
>
>
> ---------------------------------------------------------------------
> 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: Rapidly-changing revision number

[Kenneth Porter <sh...@sewingwitch.com>]

--On Friday, October 13, 2006 4:51 PM -0400 Frank Gruman 
<fg...@verizon.net> wrote:

> I think the discussion of the revision as a timestamp is a bit vague.  To
> elaborate on it, the timestamp is used to identify the state of the
> repository at virtually any given time.  This  is where the discussion
> goes on a tangent about creating separate repositories for unrelated
> projects.
> My preference and the way I have my repos set up - each project has it's
> own repository.  If I want to do some sort of work/testing/anything to
> one, I don't have to kill the whole development process to do it.  From
> the developer perspective, they know that their code is segregated by
> project.  They don't know or care that there are one or many repositories.

Setting up projects in their own repositories makes sense if they're 
independent. If one project depends on another, or they share a common 
library project, then a shared repository insures that changes in the 
depended-upon project that break the dependent project can be identified 
and rolled back.

Alas, the real world is full of coupling between projects, so one is 
tempted to put all projects in one repo. But separate repos tend to be 
easier to admin. So it depends on just how much coupling there is between 
the projects.

If you've got good interface boundaries that can be represented by a repo 
tag, then separate repos are tenable, as changes to the library are 
captured in tags and the dependent project can specify the tag(s) that it's 
compatible with.


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

Re: Rapidly-changing revision number

[Frank Gruman <fg...@verizon.net>]

Kenneth Porter wrote:
> --On Friday, October 13, 2006 1:12 PM -0500 Ted Dennison 
> <de...@ssd.fsi.com> wrote:
>
>> Wasn't there recently an argument here for multiple repositories, on the
>> basis that working with revisions can get annoying when the entire
>> repository (and thus every "project" in it) gets a new revision every
>> time something changes?
>
> "Annoying"? That's hardly a good technical argument. (I realize you're 
> quoting a previous thread and that it's not your argument.)
>
> The revision is not unlike a timestamp. Would one complain that every 
> check-in has a unique timestamp?
>
> 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.
>
My 2 cents on revision changing analogies -

If I change a file in a project containing 1000 other files and then 
test it on my local working copy before I let anyone else use it and 
then I commit those changes, I know that my one file change did not 
break the whole program in that one revision.  I can always tell the 
state of the entire project (repository) at the point in time where I 
changed the one file.

In a file-based revisioning system I might change file 1, and Joe Blow 
sitting down the hall changes file 487 with some dependencies on file 
1.  His file looks good to him, and he checks it in.  My file looks good 
to me, and I check mine in.  The project breaks.  At that build point, 
who do you point the finger at?  Was it Joe Blow's changes, or mine?  At 
what point in time did the project break, and can you role the whole 
thing back to a usable,working state easily?

I think the discussion of the revision as a timestamp is a bit vague.  
To elaborate on it, the timestamp is used to identify the state of the 
repository at virtually any given time.  This  is where the discussion 
goes on a tangent about creating separate repositories for unrelated 
projects. 

My preference and the way I have my repos set up - each project has it's 
own repository.  If I want to do some sort of work/testing/anything to 
one, I don't have to kill the whole development process to do it.  From 
the developer perspective, they know that their code is segregated by 
project.  They don't know or care that there are one or many repositories.

Regards,
Frank

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

Re: Rapidly-changing revision number (was: First-time user (Windows platform))

[Troy Curtis Jr <tr...@gmail.com>]

On 10/14/06, Kevin Greiner <gr...@gmail.com> wrote:
> On 10/13/06, Les Mikesell <le...@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

Re: Rapidly-changing revision number (was: First-time user (Windows platform))

[Kevin Greiner <gr...@gmail.com>]

On 10/13/06, Les Mikesell <le...@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.

Re: Rapidly-changing revision number (was: First-time user (Windows platform))

[Les Mikesell <le...@gmail.com>]

On Fri, 2006-10-13 at 11:43 -0700, Kenneth Porter wrote:

> > Wasn't there recently an argument here for multiple repositories, on the
> > basis that working with revisions can get annoying when the entire
> > repository (and thus every "project" in it) gets a new revision every
> > time something changes?
> 
> "Annoying"? That's hardly a good technical argument. (I realize you're 
> quoting a previous thread and that it's not your argument.)
> 
> The revision is not unlike a timestamp. Would one complain that every 
> check-in has a unique timestamp?

Yes, I'd expect people to complain if timestamps changed on files
that weren't related to the one(s) that changed.

> 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.

-- 
  Les Mikesell
   lesmikesell@gmail.com


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