[superversion] Version number methodology in a server configuration

Hello,

 

In trying to teach myself how to use Supeversion 2 in server mode (and version control methodology in general, which could be most of my problem , and I'm having trouble understanding how the auto-created version numbers are supposed to make sense.

 

Say I have 3 people start work on a new project (starting at state 1.1) in a server-based Superversion setup.  Now, person 1 edits file A, person 2 edits file B, and person 3 edits file C.  Whoever commits first, is going to get the next subversion, 1.2.  Whoever commits next is going to create a branch, and get a new major version, 2.1. Whoever commits third will get another major version, 3.1. 

 

This seems counter-intuitive, no?  I wouldn't expect one of the 3 to get a subversion, and the other 2 to get new major versions of the project.  It seems to me if this development cycle continues for long enough I'll have a whole bunch of major version numbers, and we'll constantly have to be merging back into the "mainline" version 1.

 

I could see how this methodology came about from a single-user perspective: a completely different change off of a previous version would indicate the potential start of a new major version number, otherwise each regular change results in a new sub-version. But in a multi-user environment where users are working on the same release but managing different files, saying that commit #2 by a different person means the start of a new major version is confusing to me.

 

What if each commit made by a different person off of the 1.1 fileset always resulted in a new subversion (instead of new major versions), *unless* it was a change of a file already modified and committed by another user?  e.g. start with all 3 users at 1.1 again, and all 3 editing different files. When the first person commits they get 1.2, when the second user commits they get 1.3, and when the third user commits they get 1.4.  But then say person A and person B both edit the same file off of version 1.4.  When person B commits they get 1.5, but when person A commits changes to the same file, they get 2.1 and have to merge back. That would make a lot more sense to me, it seems. Perhaps that's too complicated in a multi-file edit and commit situation though.

 

Perhaps someone can just explain to me how these version numbers in superversion are supposed to be thought of? They don't seem to follow the normal model of software versioning (ie: version 1.0 is the original, 1.1 is an update/patch fix, 1.2 is another update/patch fix, 2.0 is the next major feature release, etc).  I suspect that perhaps I should be using markers to track software versions, and think about superversion "version numbers" as more of a primary key representing changes made to a project. In that case I need help understanding the concept of markers and how they should be used and when they should move vs. when they should not (I couldn't find enough documentation on markers either).

 

Thanks!  Appreciate any help or clarification anyone can provide.

Darren Cook
Enterprise Data Services - Applications & Tools
Cingular Wireless
darren.cook <at> cingular.com

"I love deadlines. I especially like the whooshing sound they make as they go flying by."  ~Douglas Adams

 

[superversion] Feature request

Re: [superversion] Feature request

Good points. The history view has to be revamped anyway, its flaws
become more and more apparent the larger your project is. I plan on
doing that soon.

I also agree with the merge suggestion. I think one should invoke the
merge dialog first and then choose what to merge. The "object-oriented"
approach (select object, then choose action) doesn't fit well here.

-Stefan

Cook, Darren wrote:

> I'd like to request a couple of features (hopefully simple ones):
>  
> In the History screen:
>     Highlight the "work area state" shape with a different color.
> In the Markers popup window:
>     Allow a user assignable color for each marker, and use this to
> modify the color of the shape a marker is assigned to.
> See attached gif for an example of the results of the above two
> features. Of course I realize functionality in general is probably
> more important than eye candy at this point, but changing the colors
> for markers and the work area state does make the history easier to read.
>  
> In the Merge Preview dialog box:
>     Add a back button so you can more easily choose a different
> reference state to preview (without having to cancel and start from
> the beginning).
>  
> Thanks! 
>
> */Darren Cook/*
> *Enterprise Data Services - Applications & Tools*
> *Cingular Wireless*
> darren.cook <at> cingular.com
>

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [superversion] Version number methodology in a server configuration

Hi Darren!

The numbering scheme is actually quite simple.

It works like this. In the standard linear case, where every state has
at most one successor, only the minor number is incremented. As soon as
a second successor is added to a state, a new major number is chosen
(the smallest one available) and the minor number is reset to one. Same
with the third and all further successors.

As a result, the current major number of a project is more or less a
random value. It's somewhere between 1 and the total number of
branchings (that's the justifiable part) and simultaneous update
conflicts (that's the stupid part) within the project lifetime.

To give users a bit more choice over version numbers, one could invent a
different way of distinguishing branches, for example adding a letter
(1.1, 1.2, 1a.1, 1a.2, 1a.3, 1b.1, ...). Then only the letters would be
semi-random. Major numbers could be kept stable until they are
explicitly incremented by the user.

My reasoning has always been that system-generated version numbers don't
have to conform to any "real" version numbers. The marker system is
meant to handle those (For example, create a marker called "Release
1.2"). It's a bit unfortunate that "x.y" looks so much like version
numbers commonly used for software releases. If it's just looks, one
could easily change that to something like "v1_4" instead of "1.4".

I have to admit I didn't read through the details of all your
examples... If I missed a major point of yours in this answer, please
give me a good slap on the head, and I will take the time to study them :)

Cheers,
-Stefan

Cook, Darren wrote:

> Hello,
>  
> In trying to teach myself how to use Supeversion 2 in server mode (and
> version control methodology in general, which could be most of my
> problem , and I'm having trouble understanding how the auto-created
> version numbers are supposed to make sense.
>  
> Say I have 3 people start work on a new project (starting at state
> 1.1) in a server-based Superversion setup.  Now, person 1 edits file
> A, person 2 edits file B, and person 3 edits file C.  Whoever commits
> first, is going to get the next subversion, 1.2.  Whoever commits next
> is going to create a branch, and get a new major version, 2.1. Whoever
> commits third will get another major version, 3.1. 
>  
> This seems counter-intuitive, no?  I wouldn't expect one of the 3 to
> get a subversion, and the other 2 to get new major versions of the
> project.  It seems to me if this development cycle continues for long
> enough I'll have a whole bunch of major version numbers, and we'll
> constantly have to be merging back into the "mainline" version 1.
>  
> I could see how this methodology came about from a single-user
> perspective: a completely different change off of a previous version
> would indicate the potential start of a new major version number,
> otherwise each regular change results in a new sub-version. But in a
> multi-user environment where users are working on the same release but
> managing different files, saying that commit #2 by a different person
> means the start of a new major version is confusing to me.
>  
> What if each commit made by a different person off of the 1.1 fileset
> always resulted in a new subversion (instead of new major versions),
> *unless* it was a change of a file already modified and committed by
> another user?  e.g. start with all 3 users at 1.1 again, and all 3
> editing different files. When the first person commits they get 1.2,
> when the second user commits they get 1.3, and when the third user
> commits they get 1.4.  But then say person A and person B both edit
> the same file off of version 1.4.  When person B commits they get 1.5,
> but when person A commits changes to the same file, they get 2.1 and
> have to merge back. That would make a lot more sense to me, it seems.
> Perhaps that's too complicated in a multi-file edit and commit
> situation though.
>  
> Perhaps someone can just explain to me how these version numbers in
> superversion are supposed to be thought of? They don't seem to follow
> the normal model of software versioning (ie: version 1.0 is the
> original, 1.1 is an update/patch fix, 1.2 is another update/patch fix,
> 2.0 is the next major feature release, etc).  I suspect that perhaps I
> should be using markers to track software versions, and think about
> superversion "version numbers" as more of a primary key representing
> changes made to a project. In that case I need help understanding the
> concept of markers and how they should be used and when they should
> move vs. when they should not (I couldn't find enough documentation on
> markers either).
>  
> Thanks!  Appreciate any help or clarification anyone can provide.

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

RE: [superversion] Version number methodology in a server configuration

Hi Stefan,

The problem with markers is that anyone can move them, so you can't
guarantee that the release is what it says it is.

In order to use markers as release labels safely, you would need a
prelabel (premarker) trigger that checks the marker name itself to see
if it is a release label, and then if yes, checks who is doing the
labelling (e.g. only the project leader or admin can move/assign a
release label).

Best regards,
Paul

-----Original Message-----
From: superversion-discussion-admin <at> lists.sourceforge.net
[mailto:superversion-discussion-admin <at> lists.sourceforge.net] On Behalf
Of Stefan Reich
Sent: Monday, 5. September 2005 7:04 PM
To: superversion-discussion <at> lists.sourceforge.net
Subject: Re: [superversion] Version number methodology in a server
configuration

Hi Darren!

The numbering scheme is actually quite simple.

It works like this. In the standard linear case, where every state has
at most one successor, only the minor number is incremented. As soon as
a second successor is added to a state, a new major number is chosen
(the smallest one available) and the minor number is reset to one. Same
with the third and all further successors.

As a result, the current major number of a project is more or less a
random value. It's somewhere between 1 and the total number of
branchings (that's the justifiable part) and simultaneous update
conflicts (that's the stupid part) within the project lifetime.

To give users a bit more choice over version numbers, one could invent a
different way of distinguishing branches, for example adding a letter
(1.1, 1.2, 1a.1, 1a.2, 1a.3, 1b.1, ...). Then only the letters would be
semi-random. Major numbers could be kept stable until they are
explicitly incremented by the user.

My reasoning has always been that system-generated version numbers don't
have to conform to any "real" version numbers. The marker system is
meant to handle those (For example, create a marker called "Release
1.2"). It's a bit unfortunate that "x.y" looks so much like version
numbers commonly used for software releases. If it's just looks, one
could easily change that to something like "v1_4" instead of "1.4".

I have to admit I didn't read through the details of all your
examples... If I missed a major point of yours in this answer, please
give me a good slap on the head, and I will take the time to study them
:)

Cheers,
-Stefan

Cook, Darren wrote:

> Hello,
>  
> In trying to teach myself how to use Supeversion 2 in server mode (and

> version control methodology in general, which could be most of my 
> problem , and I'm having trouble understanding how the auto-created

> version numbers are supposed to make sense.
>  
> Say I have 3 people start work on a new project (starting at state
> 1.1) in a server-based Superversion setup.  Now, person 1 edits file 
> A, person 2 edits file B, and person 3 edits file C.  Whoever commits 
> first, is going to get the next subversion, 1.2.  Whoever commits next

> is going to create a branch, and get a new major version, 2.1. Whoever

> commits third will get another major version, 3.1.
>  
> This seems counter-intuitive, no?  I wouldn't expect one of the 3 to 
> get a subversion, and the other 2 to get new major versions of the 
> project.  It seems to me if this development cycle continues for long 
> enough I'll have a whole bunch of major version numbers, and we'll 
> constantly have to be merging back into the "mainline" version 1.
>  
> I could see how this methodology came about from a single-user
> perspective: a completely different change off of a previous version 
> would indicate the potential start of a new major version number, 
> otherwise each regular change results in a new sub-version. But in a 
> multi-user environment where users are working on the same release but

> managing different files, saying that commit #2 by a different person 
> means the start of a new major version is confusing to me.
>  
> What if each commit made by a different person off of the 1.1 fileset 
> always resulted in a new subversion (instead of new major versions),
> *unless* it was a change of a file already modified and committed by 
> another user?  e.g. start with all 3 users at 1.1 again, and all 3 
> editing different files. When the first person commits they get 1.2, 
> when the second user commits they get 1.3, and when the third user 
> commits they get 1.4.  But then say person A and person B both edit 
> the same file off of version 1.4.  When person B commits they get 1.5,

> but when person A commits changes to the same file, they get 2.1 and 
> have to merge back. That would make a lot more sense to me, it seems.
> Perhaps that's too complicated in a multi-file edit and commit 
> situation though.
>  
> Perhaps someone can just explain to me how these version numbers in 
> superversion are supposed to be thought of? They don't seem to follow 
> the normal model of software versioning (ie: version 1.0 is the 
> original, 1.1 is an update/patch fix, 1.2 is another update/patch fix,

> 2.0 is the next major feature release, etc).  I suspect that perhaps I

> should be using markers to track software versions, and think about 
> superversion "version numbers" as more of a primary key representing 
> changes made to a project. In that case I need help understanding the 
> concept of markers and how they should be used and when they should 
> move vs. when they should not (I couldn't find enough documentation on

> markers either).
>  
> Thanks!  Appreciate any help or clarification anyone can provide.

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
superversion-discussion mailing list
superversion-discussion <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/superversion-discussion

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

[superversion] Branching

Re: [superversion] Version number methodology in a server configuration

Adams Paul (TTE) wrote:

>Hi Stefan,
>
>The problem with markers is that anyone can move them, so you can't
>guarantee that the release is what it says it is.
>  
>
Not all users - only Core Developers and Administrators. Semi-trusted
contributors can be registered as External Developers; they can upload
states, but not move markers.

Cheers,
-Stefan

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [superversion] Branching

Jim Frazer wrote:

> Hi,
>
> I’m a new user of SuperVersion and am quite pleased so far. I am a
> remotely located developer for our software team and am able to
> connect via VPN to the SuperVersion server that runs on a network
> server at the central office.
>
> I have seen references to “Branching” at the SuperVersion web page but
> I have not yet been able to figure out how it works. How do I, as a
> single user, create a branch in the revision tree?
>
The branching in Superversion is somewhat implicit. You don't say "I
want a new branch now" and create it. It's being created as soon as you
have the first set of changes that is supposed to go into a new branch.

What you do is just "update" (or rather backdate) the work area to the
state where you want to attach the branch. If you commit a change set
now, it will be the beginning of a new branch. Branches themselves are
not first-class citizens in Supeversion, that is, they don't have names.
You can and should, however, create a marker and have it point to the
current state of the branch. One could conceive the GUI offer doing that
for you automatically.

Cheers,
-Stefan

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

[superversion] Superversion with PHP

Re: [superversion] Superversion with PHP

Hi Owen, thanks for writing in.

Owen Cole wrote:
> Greeetings Stefan,

You got my name right on first attempt, congrats :D

> First I thank you for your contribution to the community, I just 
> installed the beta 8 server and the client on a few machines.  On my LAN 
> everything is perfect.  I am the primary developer and I have a part 
> time developer that works with me.  My boss also does the graphic design 
> for the projects and has access to the repository as well.  I setup 
> individual accounts for each person, and I also setup an admin account 
> on the server that has its workspace pointed to our test web server.  We 
> also have our local workspaces pointed to web servers on our local 
> machine.  When we have something to go to our public test server, I 
> login to the admin account and synchronize with the repository.

So you have a remote desktop on the server or something? BTW, I have 
half-implemented a framework for having workspaces on a server while 
running the GUI on the client. Over HTTP, with a simple PHP script as 
backend, it already works quite nicely.

Say, in your little group, do you have any problems with merging 
concurrent changes? Although it generally works and is done 
semi-automatic by Superversion, this is something that probably needs to 
be improved upon quite urgently. The system doesn't scale too well to 
more than a few users.

> I hope I am using the setup correctly as I am very new at using version 
> control systems, but desperately needed something once I came under 
> control of this multi-developer setup.  I would greatly appreciate any 
> tips as to how to better utilize your software.

So you're starting your version control career with Superversion. Good 
good. You should definitely try command-line CVS one day just to get a 
feeling for the sheer horror others go through when they start messing 
with version control ;)

> I have one question though.  I am trying to connect with the client 
> program outside of the LAN to the office server.  I opened up ports 
> 20022 to 20023 as TCP/UDP ports that redirect to the server. I have also 
> tried fooling around with starting the server under the various ip 
> addresses and dns names I have for this server in the server GUI.  One 
> thing to note is that I am using a Linksys VOIP router for Vonage.  Is 
> there some type of special protocol that your program utilizes?  I have 
> similar communication issues when I try to connect to the VPN because my 
> router apparently doesn't support the right protocol for it.

The protocol is standard RMI (which, on a lower level, is just a bunch 
of TCP connections - no UDP). The client thus needs to open direct 
socket connections to ports 20022/20023 on the server. The other 
direction is not used (and I intend to keep it that way), so it's fine 
if the client is behind a firewall. The name you're entering in the 
Server GUI must be one that the client can resolve to the server's 
external IP address.

What you could do to track down the problem is start the server and run 
telnet on the client (going to port 20022). You should get a connection, 
and if you type something and press enter, the connection is closed, 
probably with some random characters printed.

> I hope there is a simple fix for this on my end that I have overlooked.  
> If not, at least you are aware of it.  My temporary solution is to still 
> edit the files remotely via ftp server directly on the test web server 
> and commit the changes from there accordingly.

I am routinely connecting to a Superversion server through a firewall, 
but that's the other direction (client firewalled)... I see no reason 
why your scenario shouldn't work though, given proper port forwarding.

> Anyway I thank you again, and I hope that I may contribute to this app 
> that is perfect in so many ways.

That's quite some praise... comments like this sure keep me motivated! 
Could you maybe rephrase this in a complete paragraph that explains why 
you decided to use the software and what you like about it? My quotes 
page can use an update. :) Code contributions are of course always 
welcome too.

BTW, a note for all you folks: The next release is quite near. Better 
integration for external diff tools is done, responsiveness of the 
application has improved a great deal, and I'm working on a more 
informative and flexible update dialog.

Cheers,
-Stefan

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf