Build Numbers for projects sharing the same repository?
I know it's trivial to use the repository revision property to track changes and generate build numbers for a single project. But what about when a single repository hosts more than one project in it's tree? Does anyone have any experience with using hook scripts to track, adjust, and generate build numbers for projects within a repsitory?
Why not just use the revision number as a build number? Seems like a very good approach to me; you'll always be exactly sure that the build number corresponds to an exact set of code.
Of course I would IF there was only one project per repository. But I do not want to track progress or changes in one project when I only want it for another. As an example, let's say the repository is at revision 12. And the projects are laid out in the repository as: /root_of_repository /project_1 /project_2 /project_3 If I make a change to project_1, the ENTIRE repository is changed to revision 13. I do not want this as a build number for project_2 or project_3. I want seperate indications for each of the sub-directories. Does that make sense?
Revision numbers used for build At work we have several projects in development at the same time, we split our server into several repos... /subversionhome/Projects/ /subversionhome/Projects/Project1 /subversionhome/Projects/Project2 etc and /subversionhome/Shared/ /subversionhome/Shared/Tech /subversionhome/Shared/Globals etc We did this because we didn't want commits from shared, or different projects incrementing version numbers on none related projects. So each project has a seperate repos (as does each shared code component). At build time of the exe, we had a pre-build step (in python) that just took the SVN repos number from your build DIR for each of the components (the project, and each of the shared) and had them accessable from within the application. Basically, when people report bugs back, they give us the build numbers and we are able to track what version they are using, including shared components. Hope this helps.
While I appreciate both replies, they are not really helpful. Perhaps I am not being clear? If so, I apologize. Let me try again: I would like to know if some one has an existing method to have build numbers for projects that share a repository.
James JeffersWhile I appreciate both replies, they are not really helpful. Perhaps I am not being clear? If so, I apologize. Let me try again: I would like to know if some one has an existing method to have build numbers for projects that share a repository.It seems that you want to have some sort of numbering system for the individual builds you may do on individual projects. There is only one number that can be provided by subversion and that would be the revision number of the whole repository. If you expect subversion to give you anything else, it will have to be a custom solution that you implement yourself. There are a lot of different approaches you can take. I can only offer you the approach I use in my own usage of subversion. Software revisions, in my experience are usually seperate from source code repository revisions. I utilize a 3 number combination to accomplish versioning: [SWMajorRev].[SWMinorRev].[SrcRev] i.e. 1.5.1458 or 1.5 Build (1458) where SWMajorRev = the Major version number of the software SWMinorRev = the Minor version number of the software SrcRev = the [i]Subversion[/r] repository version of the build By including the repository version in the actual version number, I can be certain to reference the exact code used to build a particular version. If I used some other number based upon the actual tree, it would be useless for anything more than a cosmetic representation. As a developer, support rep, content manager, etc. I need an actual repository revision. For me, anything more flexible than this is a administrative hassle that I don't care to deal with. -Mut13y
This seems to be the only thing about Subversion I have ever felt let down by. It would seem to be to a trivial, but valuable feature to be able to glean revisions based on tags or paths, in _addition to_ the entire repository. Yes, I could break up the repository, but then I'd be duplicating the effort amongst several repsoitories writing and maintain support mechanisms such as hook scripts, etc. I wonder, is it possible to share items via svn:external across repositories?
If increasing-by-1 version numbers are that important to you, you should just use several repositories. Subversion has chosen to use a global revision number for a very good reason (to identify the whole tree, not just a file - directories are versionable, too), and so it would not make sense for SVN to have distinctive version numbers on different directories. I thinking the additional maintenance effort of maintaining several repositories is hardly significant (especially if you do something like a sym-link to a shared hooks-dir or whatever - and it allows for different hookscripts depending on your project). What do you mean by sharing items?
I'm not sure I understand your hesitation in using the repository number as it's intended. That number represent any directory, file, or set of files in the repository at a given time. svn:external would allow you to attach other repositories to your tree, but there are allowances you must make to incorporate such a solution. If "Sharing" code, as you put it, is something you need to do for your project to be complete, I would think you'd want it in a single repository; with a single revision number. If you have a source file, say foo1.c, in svnrepo1 and it depends on foo2.c in svnrepo2 you run the risk of losing compatibility for, what I consider, obvious reasons. if svnrepo1 is at version 205 and svnrepo2 is at version 133 you have to be aware of 2 separate version numbers for 2 separate components that make a single set of code. I celebrate subversion's use of a single version number. It is guaranteed to be unique for the whole set of source. With one number I can get whatever I want from a repository regardless of it's location. If I'm off base with this post, maybe you should explain, specifically, what you are hoping to get help with. -Mut13y
"mut13y"[quote=James Jeffers]I utilize a 3 number combination to accomplish versioning: [SWMajorRev].[SWMinorRev].[SrcRev] i.e. 1.5.1458 or 1.5 Build (1458) where SWMajorRev = the Major version number of the software SWMinorRev = the Minor version number of the software SrcRev = the Subversion repository version of the buildHi all, i'm new to the forums, and i've a question! I'm trying the method i quoted from mut13y: how can u have a "clean" revision number from a $rev$ keyword?! This keyword is replaced by SVN and it places some extra stuff with the number so have u to parse it at runtime?! I know you can use svnversion but how to retrieve it from a source file?! Thank you anyone!
Manny79how can u have a "clean" revision number from a $rev$ keyword?! This keyword is replaced by SVN and it places some extra stuff with the number so have u to parse it at runtime?! I know you can use svnversion but how to retrieve it from a source file?!Just have the $rev$ number expand itself inside a variable and write a small routine to parse the variable. -Mut13y
Yes, this is what i coded, thank you! Also, i changed the way i get the revision number, because the $Rev$ keyword has the file revision and not the project-level revision! So, if you want to have a project-level revision number, you must use svnversion or the $WCREV$ keyword that the TortoiseSVN\bin\subwcrev.exe tool in TortoiseSVN can substitute in a template file for you. Svn has no keywords that can give you the whole repository revision number, so you must think how to use either subwcrev or svnversion tools.
The "project-level revision" as you called it gets updated each time any file in the project is changed, correct? /proj - 123 /proj/asdf.c - 111 /proj/asdf.h - 123
Yep AndrewKT, sure!
Mut13y, Wow, I must have not had coffee that morning. I seemed so cranky. After a long hiatus from this problem, I must say I agree with your stance - the revision number for a repository serves my purpose completely. Even with a hetergenous project layout, the revision number references an exact instance of the source code (and hence, any products of using that code, ie, a build). Thanks for your help!
No problem, happy you resolved too ;)
James Jeffers... Wow, I must have not had coffee that morning. I seemed so cranky. ...Happens to me all the time... I usually wait till after lunch before I hit any forums... 8) (I'm usually at 5 cups of coffee by then.) I'm glad you have warmed up to the revision number paradigm. When I was first exposed that the version numbering in subversion I was a little confused, but then it hit me like a truck and I couldn't think of trying to do it any other way. I have to use SourceSafe here where I work. (Anything more difficult than that confuses our developers - pretty sad) I hate VSS more and more with each passing day. So I guess I can blame some of the frustration at my job on subversion. :wink: -Mut13y
In danger of hijacking my own thread... I also have to use VSS - and I have to use it on Linux and Solaris as well as Windows. In a perfect world, I'd push hard for our shop to move to Subversion. However, given the learning curve from VSS to Subversion, I think we're going to go with SourceGear's Vault.
1-18 of 18
Reply to this discussion
You cannot edit posts or make replies: You should be logged in before you can post.