You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alan Jay Weiner <al...@ajw.com> on 2005/09/15 19:10:21 UTC
per-project version numbers - a way to support them? (without changing Subversion!?)
I apologize for the lenght of this - the examples make it quite long, but I
think make it clearer than just a description...
Like others coming from other revision systems, I'm bothered by repository-wide
version numbers. (I've accepted it, but it keeps coming up with clients - "why
is this version X+N instead of X+1?")
Just saying "get used to it" isn't an answer to those who don't *want* it to
work that way.
I haven't thought this through extensively - it's partially
stream-of-conciousness - but could per-project version numbers be handled by
properties set on directories and files?
Say you have a repository with two projects:
svnrepo
project1
trunk
sources
file1.c
file2.c
docs
tests
branches
tags
project2
trunk
notes
to-do.txt
branches
tags
Subversion itself works as it does now, keeping repo-wide version numbers; *no*
change to that behavior.
Each directory (possibly each file?) would have a property - let's call it
'myversion'.
Let's start with the above repo, and create it from scratch. (sorry this will
make this email long, but I think will be clearer...)
We create the repo; it's empty. Subversion is at version 1:
svnrepo
Now we create project1:
svnrepo
project1
Subversion's version is at 2, the 'myversion' property attached to the directory
'project1' is 1.
svnrepo
project1
project2
Now we create project2. Subversion's at version 3, project2's myversion = 1,
and (here's the per-project goodie) project1's myversion is still = 1.
Now we create the trunk, branches, and tags directories for project1:
svnrepo
project1
trunk
branches
tags
Re: per-project version numbers - a way to support them? (without changing Subversion!?)
Posted by Alan Jay Weiner <al...@ajw.com>.
>> repository-wide version numbers...
>Besides really having the urge to say "get used to it", I have to
>wonder why you think revision numbers in your subversion repository
>matter in the slightest? Why are your clients looking at the
>revision numbers at all?
Well, in the same vein as "get used to it", uh... "because they are" :)
(although they *aren't* any more... :)
In one case I provided the Subversion log as a list of changes - naturally it
showed the Subversion version number, and that led to questions about what
happened in the "missing" revisions. I explained, but they seemed uncomfortable
with it anyway.
After thinking about it more, maybe the best answer *is* "get used to it".
It was one of my concerns when I first started using Subversion, and I've seen
others ask about it (always coming from SourceSafe if I remember right...)
Mostly it's a change from "how I've always done it" - as I said, I've gotten
used to it, but some part of me still prefers per-project version numbers...
(no! I'm not going back to VSS!! :)
>It's not like the numbers have any significant meaning. If the
>number is 12 for one "version" on your project and "1345" for the
>next, what does that really mean? The revision number getting bumped
>doesn't correspond to any logical unit of change in the project, even
>if you do have one revision number per project. E.g. it goes up even
>when you revert a change and move backwards.
True... It's hanging importance on numbers that really *aren't* important....
>Is there a reason you can't use the one project per repository model?
Just inertia - I've got a dozen projects in my repo already...
>If you could explain the rational for needing subversion to track per-
>project version numbers in the first place it might help generate
>some ideas. I.e. why exactly is it that you don't want it to work
>the way it does now? What problem are you trying to solve?
>My first inclination would be to simply stop giving the revision
>information to your clients... then they won't have anything to ask
>questions about :).
That's exactly what I've done - the project tracks "version numbers" separately,
and I use the subversion version number as a build number (so I can relate
builds back to specific repo versions)
Maybe I *am* trying to solve a non-problem...
I *do* do that occasionally... :)
Good questions, Scott - and since I don't have good answers, I'm inclined to
agree that it's a non-issue. Especially since I've already gotten used to it.
:)
- Al -
--
-- Alan Weiner -- alan@ajw.com -- http://www.ajw.com
Palm OS Certified Developer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: per-project version numbers - a way to support them? (without changing Subversion!?)
Posted by Scott Palmer <sc...@2connected.org>.
On 15-Sep-05, at 3:10 PM, Alan Jay Weiner wrote:
> Like others coming from other revision systems, I'm bothered by
> repository-wide
> version numbers. (I've accepted it, but it keeps coming up with
> clients - "why
> is this version X+N instead of X+1?")
> Just saying "get used to it" isn't an answer to those who don't
> *want* it to
> work that way.
Besides really having the urge to say "get used to it", I have to
wonder why you think revision numbers in your subversion repository
matter in the slightest? Why are your clients looking at the
revision numbers at all?
It's not like the numbers have any significant meaning. If the
number is 12 for one "version" on your project and "1345" for the
next, what does that really mean? The revision number getting bumped
doesn't correspond to any logical unit of change in the project, even
if you do have one revision number per project. E.g. it goes up even
when you revert a change and move backwards.
You can already get the version number of the last change to a folder/
file:
$ svn info
Path: .
URL: svn://myserver/myproject/trunk
Repository UUID: bb17bfd5-26e3-0310-b67b-ca9ce5c526f2
Revision: 2788
Node Kind: directory
Schedule: normal
Last Changed Author: scott.palmer
Last Changed Rev: 2775
Last Changed Date: 2005-09-12 21:13:12 -0400 (Mon, 12 Sep 2005)
Properties Last Updated: 2005-04-29 16:51:32 -0400 (Fri, 29 Apr 2005)
Will "Last Changed Rev:" or perhaps some fancy script involving
finding the greatest " Last Changed Rev" in a tree get you want you
want?
Is there a reason you can't use the one project per repository model?
> Ideas, anyone?
If you could explain the rational for needing subversion to track per-
project version numbers in the first place it might help generate
some ideas. I.e. why exactly is it that you don't want it to work
the way it does now? What problem are you trying to solve?
My first inclination would be to simply stop giving the revision
information to your clients... then they won't have anything to ask
questions about :).
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org