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

From here on, I'll show the Subversion version number as [n] and the myversion
property value as (x). So we have:
Subversion's version is now at 6. The myversion values for each directory are:

        svnrepo [6]
                project1 (4)
                        trunk (1)
                        branches (1)
                        tags (1)
                project2 (1)

Now we add subdirectories to project1/trunk. As we do this, the myversion
property on each parental directory is incremented:
(assume I created each directory on the repo individually, so the SVN version
bumps by 3)

        svnrepo [9]
                project1 (7)
                        trunk (4)
                                sources (1)
                                docs (1)
                                tests (1)
                        branches (1)
                        tags (1)
                project2 (1)

Now adding files to project1\trunk\sources:
(again individually, so Subversion's version number goes up by 2)
Note that project1, project1\trunk, and project1\trunk\sources all increment
their myversion value, too.

        svnrepo [11]
                project1 (10)
                        trunk (6)
                                sources (3)
                                        file1.c (1)
                                        file2.c (1)
                                docs (1)
                                tests (1)
                        branches (1)
                        tags (1)
                project2 (1)

Now we add subdirectories and files to project2:

        svnrepo [15]
                project1 (10)
                        trunk (6)
                                sources (3)
                                        file1.c (1)
                                        file2.c (1)
                                docs (1)
                                tests (1)
                        branches (1)
                        tags (1)
                project2 (6)
                        trunk (3)
                                notes (2)
                                        to-do.txt (1)
                        branches (1)
                        tags (1)

Then editing files in project1 - let's edit and check in file1.c.
Now we have:

        svnrepo [16]
                project1 (11)
                        trunk (7)
                                sources (4)
                                        file1.c (2)
                                        file2.c (1)
                                docs (1)
                                tests (1)
                        branches (1)
                        tags (1)
                project2 (6)
                        trunk (3)
                                notes (2)
                                        to-do.txt (1)
                        branches (1)
                        tags (1)

You can see that you can get a per-project (or per-directory/per-file) version
number that's specific to that project, directory, or file.

What you consider the build's version number is determined by the myversion in
the directory you specify.

So even though Subversion says I'm at version 16, my project1 (or more
accurately, project1\trunk\sources - because that's the parent for my source
files) say that project1 is at version 4 - that's the version my client sees,
and could be displayed by project1's executable.

I think this'll work with cheap copies to tags and branches - they'll keep the
same myversion property values, but I'm not sure about what to do with moving
files or directories (you could end up with file foo at myversion=555 and the
directory above it at myversion=3 - odd, but makes sense following the file and
dir's history)

I think this could be done just by wrapping svn checkin, but anyone using a gui
front-end (I use TSVN) can't do it that way. (or can we? if anyone knows a
way, please mention it)

It can't (or shouldn't) be done by hook scripts because that'd modify the files
and dirs being checked in (along with those above)

Should the property modifications be done directly on the repo? Otherwise I
might be out of sync with the repo on directories above what I'm checking in.
I.e., I check in file1.c, but my project1\trunk\sources myversion property is
different than the repo's - if I increment project1\trunk\sources's myversion
locally, and later check in project1\trunk\sources I'll be messing up the
myversion property.
That would be caught by Subversion though - I'd have to do an update, wouldn't
I? But then the update'll lose my incrementing the myversion (or will it? I'm
confusing myself now...)
Or will I even be able to do an update, since I've changed the directory
properties?

Again, I apologize for the length of this example.

Ideas, anyone?

- Al -

-- 
--  Alan Weiner  --  alan_at_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