Talk:Version control repository - Revision history

Scalar Tardis: /* SVN internal versioning has no relationship to public release versioning? */ I need the line numbers as found in the SVN listings

2008-06-15T08:04:32Z

SVN internal versioning has no relationship to public release versioning?: I need the line numbers as found in the SVN listings

← Older revision		Revision as of 01:04, 15 June 2008
Line 113:		Line 113:
	:As you discovered, it's kinda tough to figure out which version maps to a particular release number using svn. It's much easier to start from the [[source downloads]] page. Using 1.19.1.4 as an example, that will tell you that it's in Branch_1-19-1-Viewer as rev84244 in our internal repository, released on April 7. Skimming [http://svn.secondlife.com/trac/linden/log/branches/Branch_1-19-1-Viewer the list of changes to Branch_1-19-1-Viewer], you'll see rev 443 was released on April 7. [http://svn.secondlife.com/trac/linden/changeset/443 Inspecting the changeset and comments for external r443], you'll see that it indeed corresponds to r84244 in our internal repository, so that's 1.19.1.4.		:As you discovered, it's kinda tough to figure out which version maps to a particular release number using svn. It's much easier to start from the [[source downloads]] page. Using 1.19.1.4 as an example, that will tell you that it's in Branch_1-19-1-Viewer as rev84244 in our internal repository, released on April 7. Skimming [http://svn.secondlife.com/trac/linden/log/branches/Branch_1-19-1-Viewer the list of changes to Branch_1-19-1-Viewer], you'll see rev 443 was released on April 7. [http://svn.secondlife.com/trac/linden/changeset/443 Inspecting the changeset and comments for external r443], you'll see that it indeed corresponds to r84244 in our internal repository, so that's 1.19.1.4.
	:As for why the version isn't in the comment, I can only speculate. When I was doing it, I tried to put the version in the comment, but I was doing much more by hand (and not releasing nearly as reliably as Soft is doing it). Now that Soft has it much more automated, I suspect that he's automatically generating the comments as well, and that sort of information is probably tougher to automate. -- [[User:Rob Linden\|Rob Linden]] 23:49, 14 June 2008 (PDT)		:As for why the version isn't in the comment, I can only speculate. When I was doing it, I tried to put the version in the comment, but I was doing much more by hand (and not releasing nearly as reliably as Soft is doing it). Now that Soft has it much more automated, I suspect that he's automatically generating the comments as well, and that sort of information is probably tougher to automate. -- [[User:Rob Linden\|Rob Linden]] 23:49, 14 June 2008 (PDT)
			::Thanks, I put your info into the main page, and tried to remove any LL responsibility from updating my new list. :-)
			::And why do I explicitly want to use the SVN? Well, when I open the source files on my own computer using Windows Notepad, I don't get those line numbers in front of each line of code. I want the line numbers.
			::How am I supposed to properly quote the source on the ridiculously huge page I'm creating called [[VFS: Where it is used in the viewer]] if I cannot include line numbers in the quoted source?
			::While I could install some source viewer / text editor on my computer, it's just so much easier to skip all that and use the text direct from the SVN source pages that already have line numbers. [[User:Scalar Tardis\|Scalar Tardis]] 01:04, 15 June 2008 (PDT)

Rob Linden: /* SVN internal versioning has no relationship to public release versioning? */ - short answer: r443

2008-06-15T06:49:52Z

SVN internal versioning has no relationship to public release versioning?: - short answer: r443

← Older revision		Revision as of 23:49, 14 June 2008
Line 110:		Line 110:
	What the secret of this totally different version numbering in the svn?		What the secret of this totally different version numbering in the svn?
	[[User:Scalar Tardis\|Scalar Tardis]] 21:47, 14 June 2008 (PDT)		[[User:Scalar Tardis\|Scalar Tardis]] 21:47, 14 June 2008 (PDT)

			:As you discovered, it's kinda tough to figure out which version maps to a particular release number using svn. It's much easier to start from the [[source downloads]] page. Using 1.19.1.4 as an example, that will tell you that it's in Branch_1-19-1-Viewer as rev84244 in our internal repository, released on April 7. Skimming [http://svn.secondlife.com/trac/linden/log/branches/Branch_1-19-1-Viewer the list of changes to Branch_1-19-1-Viewer], you'll see rev 443 was released on April 7. [http://svn.secondlife.com/trac/linden/changeset/443 Inspecting the changeset and comments for external r443], you'll see that it indeed corresponds to r84244 in our internal repository, so that's 1.19.1.4.
			:As for why the version isn't in the comment, I can only speculate. When I was doing it, I tried to put the version in the comment, but I was doing much more by hand (and not releasing nearly as reliably as Soft is doing it). Now that Soft has it much more automated, I suspect that he's automatically generating the comments as well, and that sort of information is probably tougher to automate. -- [[User:Rob Linden\|Rob Linden]] 23:49, 14 June 2008 (PDT)

Scalar Tardis: /* SVN internal versioning has no relationship to public release versioning? */ formatting

2008-06-15T04:49:20Z

SVN internal versioning has no relationship to public release versioning?: formatting

← Older revision		Revision as of 21:49, 14 June 2008
Line 92:		Line 92:

	A search for "1.19.1.4" returns no results:		A search for "1.19.1.4" returns no results:

	http://svn.secondlife.com/trac/linden/search?q=1.19.1.4&wiki=on&changeset=on&ticket=on		http://svn.secondlife.com/trac/linden/search?q=1.19.1.4&wiki=on&changeset=on&ticket=on

	A search for "1.19.1" does work, but doesn't tell me anything useful:		A search for "1.19.1" does work, but doesn't tell me anything useful:

	http://svn.secondlife.com/trac/linden/search?q=1.19.1&noquickjump=1&changeset=on&wiki=on		http://svn.secondlife.com/trac/linden/search?q=1.19.1&noquickjump=1&changeset=on&wiki=on

	As I write this I am looking at "audioengine.cpp" which has the following at the top:		As I write this I am looking at "audioengine.cpp" which has the following at the top:

	''Revision 624, 32.8 kB (checked in by soft.linden, 6 days ago)		<php>Revision 624, 32.8 kB (checked in by soft.linden, 6 days ago)
	Snapshot of internal branch release		Snapshot of internal branch release
	Last Changed Rev: 89252		Last Changed Rev: 89252
	Last Changed Date: 2008-06-06 17:47:05 -0700 (Fri, 06 Jun 2008) ''		Last Changed Date: 2008-06-06 17:47:05 -0700 (Fri, 06 Jun 2008)</php>

	Buh?? Absolutely nothing here refers to 1.19.x or 1.20.x versions.		Buh?? Absolutely nothing here refers to 1.19.x or 1.20.x versions.

Scalar Tardis: /* How to look up a release version in the svn? SVN versioning has no relationship to public release versioning? */ ...shorten section name.. :)

2008-06-15T04:48:06Z

How to look up a release version in the svn? SVN versioning has no relationship to public release versioning?: ...shorten section name.. :)

← Older revision		Revision as of 21:48, 14 June 2008
Line 87:		Line 87:
	--[[User:Hegemon Skall\|Hegemon Skall]] 17:38, 27 January 2007 (PST)		--[[User:Hegemon Skall\|Hegemon Skall]] 17:38, 27 January 2007 (PST)

	== ~~How to look up a release version in the svn?~~ SVN versioning has no relationship to public release versioning? ==		== SVN internal versioning has no relationship to public release versioning? ==

	Let's say I wanted to see the code as it was released for 1.19.1.4 in the repository. How do I access this version?		Let's say I wanted to see the code as it was released for 1.19.1.4 in the repository. How do I access this version?

Scalar Tardis: New section: [[Talk:Version control repository#How to look up a release version in the svn? SVN versioning has no relationship to public release versioning?|How to look up a release version in the svn? SVN versioning has no relationship to public release

2008-06-15T04:47:11Z

New section: [[Talk:Version control repository#How to look up a release version in the svn? SVN versioning has no relationship to public release versioning?|How to look up a release version in the svn? SVN versioning has no relationship to public release

← Older revision		Revision as of 21:47, 14 June 2008
Line 86:		Line 86:
	http://en.wikipedia.org/wiki/Comparison_of_revision_control_software		http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
	--[[User:Hegemon Skall\|Hegemon Skall]] 17:38, 27 January 2007 (PST)		--[[User:Hegemon Skall\|Hegemon Skall]] 17:38, 27 January 2007 (PST)

			== How to look up a release version in the svn? SVN versioning has no relationship to public release versioning? ==

			Let's say I wanted to see the code as it was released for 1.19.1.4 in the repository. How do I access this version?

			A search for "1.19.1.4" returns no results:
			http://svn.secondlife.com/trac/linden/search?q=1.19.1.4&wiki=on&changeset=on&ticket=on

			A search for "1.19.1" does work, but doesn't tell me anything useful:
			http://svn.secondlife.com/trac/linden/search?q=1.19.1&noquickjump=1&changeset=on&wiki=on

			As I write this I am looking at "audioengine.cpp" which has the following at the top:

			''Revision 624, 32.8 kB (checked in by soft.linden, 6 days ago)
			Snapshot of internal branch release
			Last Changed Rev: 89252
			Last Changed Date: 2008-06-06 17:47:05 -0700 (Fri, 06 Jun 2008) ''

			Buh?? Absolutely nothing here refers to 1.19.x or 1.20.x versions.

			What the secret of this totally different version numbering in the svn?
			[[User:Scalar Tardis\|Scalar Tardis]] 21:47, 14 June 2008 (PDT)

Bushing Spatula: bushing speaks!

2007-02-05T10:14:41Z

bushing speaks!

← Older revision		Revision as of 03:14, 5 February 2007
Line 40:		Line 40:
	* I Agree the lack of a Distributed Version Control sucks, you've got me curious, I want to play with SVK now.		* I Agree the lack of a Distributed Version Control sucks, you've got me curious, I want to play with SVK now.

			[[User:Bushing Spatula\|Bushing Spatula]] 02:14, 5 February 2007 (PST) votes against SVN, with further comments below
			* I use SVN professionally. We have a SVN repo with hundreds of thousands of lines of code (it's something like 2.9GB including history), and roughtly a dozen developers. It works pretty well with the following use model:
			** Each dev has his own set of code -- we almost never step on each others' toes because the code is well-partitioned into subprojects
			** All patches are initially saved as a branch -- one per bug -- which is then peer-reviewed. Once it passes review, the patch is merged into trunk.
			While this may or may not be similar to how LL does things in-house with SVN, I think this is very different then allowing outside contributions from many people, many of whom will step on each others toes, and many of whom will submit patches that will not be accepted. See discussion below about distributed systems.
	== Distributed version control ==		== Distributed version control ==

	One reason I really like the distributed version control systems is because it really reduces the need for Linden Lab to be in the business of giving people their own sandboxes. Many of the newer systems are very easy to host, and merging from multiple repositories is much easier. -- [[User:Rob Linden\|Rob Linden]] 07:25, 8 January 2007 (PST)		One reason I really like the distributed version control systems is because it really reduces the need for Linden Lab to be in the business of giving people their own sandboxes. Many of the newer systems are very easy to host, and merging from multiple repositories is much easier. -- [[User:Rob Linden\|Rob Linden]] 07:25, 8 January 2007 (PST)

			I agree. Please, if you're interested in this debate, go read up on the pros and cons of distributed version control before proceeding -- it's a complicated, nuanced issue.
			My crude summary:
			* DVC systems allow everyone to set up their own private, spiffy repository. There's no need for LL to make every developer an account, because
			* It's really easy to make changes on your local repo, and really easy to integrate changes from upstream (IE new LL source drops), so you make sure your changes are still relevant and still valid with every release
			* Once you're happy with your code, it's easy to make patches that you can pass around, post on mailing lists, etc -- and other people can seamlessly drop them into their own local repository without breaking other stuff
			* Once everyone loves a patch, it's very easy to send that patch to LL in a form that is very easy for them to apply to their tree.

			I'd tend to go with Mercurial, because it seems to have the greatest support and mindshare of the DVC systems right now, but I'd be happy with any of them. [[User:Bushing Spatula\|Bushing Spatula]] 02:14, 5 February 2007 (PST)
	=== Mercurial ===		=== Mercurial ===
	Mercurial's claim: Mercurial is a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects.		Mercurial's claim: Mercurial is a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects.

Hegemon Skall: /* Bazaar */

2007-01-28T01:38:52Z

Bazaar

← Older revision		Revision as of 18:38, 27 January 2007
Line 66:		Line 66:

	Might also be worth looking at using launchpad itself which includes the Bazaar VCS, bug tracking and other stuff, The back end is closed currently but Canonical might be quite happy to allow Linden labs to have a copy of it to host, Mark Shuttleworth recently post about SL http://www.markshuttleworth.com/archives/72 although it would probably be quite a lot of work to setup and the features like bug tracking might be duplicated with existing systems used by Linden (although it seems like it would be fairly easy to integrate them. --[[User:Hegemon Skall\|Hegemon Skall]] 13:32, 26 January 2007 (PST)		Might also be worth looking at using launchpad itself which includes the Bazaar VCS, bug tracking and other stuff, The back end is closed currently but Canonical might be quite happy to allow Linden labs to have a copy of it to host, Mark Shuttleworth recently post about SL http://www.markshuttleworth.com/archives/72 although it would probably be quite a lot of work to setup and the features like bug tracking might be duplicated with existing systems used by Linden (although it seems like it would be fairly easy to integrate them. --[[User:Hegemon Skall\|Hegemon Skall]] 13:32, 26 January 2007 (PST)

			=== Comparisons ===
			Thought these might be useful, basically a list of features supported by each VCS:

			http://bazaar-vcs.org/RcsComparisons
			http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
			--[[User:Hegemon Skall\|Hegemon Skall]] 17:38, 27 January 2007 (PST)

Hegemon Skall: /* Darcs */

2007-01-26T21:32:05Z

Darcs

← Older revision		Revision as of 14:32, 26 January 2007
Line 62:		Line 62:
	[[User:Don Linden\|Don]] and [[User:Kelly Linden\|Kelly]] Linden experimented with darcs between 2006.02 and 2006.03. The version was 1.0.2 on linux. The Win and Mac versions may have been different. The conclusion was that darcs could not yet handle large repositories. -- [[User:Andrew Linden\|Andrew Linden]] 2006.01.10 09:21 (PST)		[[User:Don Linden\|Don]] and [[User:Kelly Linden\|Kelly]] Linden experimented with darcs between 2006.02 and 2006.03. The version was 1.0.2 on linux. The Win and Mac versions may have been different. The conclusion was that darcs could not yet handle large repositories. -- [[User:Andrew Linden\|Andrew Linden]] 2006.01.10 09:21 (PST)

	Bazaar seems to be the hot ~~repository~~ of choice now days, might be worth considering. Not sure if the development model is applicable to SL or not.		=== Bazaar ===
			Bazaar seems to be the hot VCS of choice now days, might be worth considering. Not sure if the development model is applicable to SL or not. It's got quite a lot of buzz recently in the Linux/Ubuntu/Launchpad world, also seems to have Windows support. http://bazaar-vcs.org/

			Might also be worth looking at using launchpad itself which includes the Bazaar VCS, bug tracking and other stuff, The back end is closed currently but Canonical might be quite happy to allow Linden labs to have a copy of it to host, Mark Shuttleworth recently post about SL http://www.markshuttleworth.com/archives/72 although it would probably be quite a lot of work to setup and the features like bug tracking might be duplicated with existing systems used by Linden (although it seems like it would be fairly easy to integrate them. --[[User:Hegemon Skall\|Hegemon Skall]] 13:32, 26 January 2007 (PST)

Hegemon Skall at 21:16, 26 January 2007

2007-01-26T21:16:18Z

← Older revision		Revision as of 14:16, 26 January 2007
Line 61:		Line 61:

	[[User:Don Linden\|Don]] and [[User:Kelly Linden\|Kelly]] Linden experimented with darcs between 2006.02 and 2006.03. The version was 1.0.2 on linux. The Win and Mac versions may have been different. The conclusion was that darcs could not yet handle large repositories. -- [[User:Andrew Linden\|Andrew Linden]] 2006.01.10 09:21 (PST)		[[User:Don Linden\|Don]] and [[User:Kelly Linden\|Kelly]] Linden experimented with darcs between 2006.02 and 2006.03. The version was 1.0.2 on linux. The Win and Mac versions may have been different. The conclusion was that darcs could not yet handle large repositories. -- [[User:Andrew Linden\|Andrew Linden]] 2006.01.10 09:21 (PST)

			Bazaar seems to be the hot repository of choice now days, might be worth considering. Not sure if the development model is applicable to SL or not.

Kunnis Basiat at 06:35, 15 January 2007

2007-01-15T06:35:34Z

← Older revision		Revision as of 23:35, 14 January 2007
Line 31:		Line 31:
	** To continue on this point, we had to repair the opensecondlife.org svn database over a dozen times while checking in the thousands of files that make up the full codebase. It's centralized atomic nature seems to start falling apart when you have very big commits or similar operations going on and multiple other people are trying to check out		** To continue on this point, we had to repair the opensecondlife.org svn database over a dozen times while checking in the thousands of files that make up the full codebase. It's centralized atomic nature seems to start falling apart when you have very big commits or similar operations going on and multiple other people are trying to check out
	* SVN is a centralized repository system, it's designed to allow a group of people work together on the same codebase. LL would either have to create two million svn accounts, or have someone take account requests and process them, including setting up permissions for each sandbox... it would become a nightmare very quickly. That's why large distributed projects like the Linux kernel used distributed version control. They use Git which is Linux only right now, but Mercurial is proving to be a very good competitor to Git with support for all major operating systems		* SVN is a centralized repository system, it's designed to allow a group of people work together on the same codebase. LL would either have to create two million svn accounts, or have someone take account requests and process them, including setting up permissions for each sandbox... it would become a nightmare very quickly. That's why large distributed projects like the Linux kernel used distributed version control. They use Git which is Linux only right now, but Mercurial is proving to be a very good competitor to Git with support for all major operating systems

			[[User:Kunnis Basiat\|Kunnis Basiat]] 22:35, 14 January 2007 (PST)
			* While I agree with the fact that branching and merging is a bit wierd in SVN, it was designed that way from the start, it was designed to get around several of the design flaws that were present in CVS, though I agree it's not as intunitive as it should be, it allows for really good tracking, but it's also a bit confusing. LL has been using SVN for a while, so they should be familiar with how version control in SVN works.
			* I Find SVN to be really stable.I've never had a problem with SVN, and I've used it for a couple years professionally, and I've been helping my latest company migrate to SVN. The only annoyance I have about SVN is it's lack of an "obliterate" command, which there is a workaround for, and the schedule of an addition of the command. Other then that issue, SVN has been in use for several years, it's a well tested tool, and if any issues arise while using it, it's likley that you can find support for it. I've only had to break out svnadmin once (to deal with the lack of obliterate, and I found a step-by-step on how to do it.)
			* SVN is used by KDE. It has both binary and source files, which reflects what we would be checking into OpenSL, and I think that KDE would have more users editing it, and I'm pretty sure it has a larger codebase.
			* I don't know what problem you had with your repo. I am using the windows version of SVN, and I took my existing repo that I've used for other projects and checked in all of the slviewer and libs in one big checkin, with no problems. It copied all ~9000 files and 160megs in about 5 mins.
			* I agree that LL creating account for every developer is very unreasonable. I think LL should host a repo that only has "gold" code on it, ready for production, with tags for each build. There should not be a sandbox for every developer. I think that we should submit patches to LL that are diffs from the head version of the repo, then a LL employee can apply the patch, then check&verify it works and passes all tests, then finally commit the patch to the repo. What would the process for a LL employee to recieve a change, validate it, and apply it to production be with Mercurial? I don't know enough about it to say what it's like.
			* I Agree the lack of a Distributed Version Control sucks, you've got me curious, I want to play with SVK now.

	== Distributed version control ==		== Distributed version control ==