RE: SVN Tag / Branch question
I am sorry to re-visit this again. Yes, we have cases where files (in the same path, i.e. trunk/docs) are intended for different releases. If as you say, we are doing something wrong, what's a better way to handle this? In /trunk/docs: Release_doc_1.5 Release_doc_1.6 Release_doc_1.7 Do you have different files in the same path that apply to different releases? If so, I think you are doing something wrong. -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, October 30, 2012 1:41 PM To: Ahmed, Omair (GE Oil Gas); users@subversion.apache.org Subject: RE: SVN Tag / Branch question You are correct in making the statement below. However, what's confusing is that when I copied the Docs directory from /trunk to /tags/release-1.6, the directory included files from the previous release also. Basically, I was expecting to see just the new files. I am trying to understand how that happened and how to prevent. I think perhaps you have a misunderstanding of how subversion revisions work. A revision contains ALL of the files in the path no matter what previous rev they were last changed in. Do you have different files in the same path that apply to different releases? If so, I think you are doing something wrong. For example, you should have... readme_v1.txt and then make a readme_v2.txt for a new release. You should just modify the readme.txt file accordingly and let svn keep track of which rev of that file goes with which release of your product. You should go and review Chapter 1 and 2 of the documentation. http://svnbook.red-bean.com/en/1.7/svn-book.html BOb Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, October 30, 2012 11:36 AM To: Ahmed, Omair (GE Oil Gas); users@subversion.apache.org Subject: RE: SVN Tag / Branch question Hello, We did our first release in SVN today. I used the copy command (shown below) to copy from /trunk to /tag. Since not everything in /trunk was needed for this release, I had to specify the directories which were needed. Q1. Is this the normal/correct way of doing things? For the new release, just the Docs, MKVIE and Screens dirs. were needed. The others were not. Not sure what you mean by not needed. However, you don't save anything by not just copying trunk to tag. Since svn uses cheap copies copying the full trunk folder doesn't take any more space than copying certain folders. Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? Our repo structure is as follows: Csvn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX Control/ Docs/ MKVIE/ Screens/ sem_modbus/ Q2. Are we better off using release branches instead of copying to /tags? To svn a copy is a copy. tags and branches are semantic names. In general a tag isn't ever committed to. But, this is only by convention. Q3. Sometime down the line, if I had to re-create a view of Release 1.6, do I just base my workspace on what's in /tags/release-1.6? Or is there another/better way of re-creating a prior release? I would copy the tag to a branch and work from the branch. Q4. I was also expecting /tags to contain just the new files for Release 1.6. However, that wouldn't be case, right? I have a feeling I am confusing myself over nothing. Basically, all a copy is, is a pointer to the location that it copied. So, the state of the path you copy to includes everything from the source path. But, once again, it is a cheap copy so no files are really copied. BOb
RE: SVN Tag / Branch question
Hello, We did our first release in SVN today. I used the copy command (shown below) to copy from /trunk to /tag. Since not everything in /trunk was needed for this release, I had to specify the directories which were needed. Q1. Is this the normal/correct way of doing things? For the new release, just the Docs, MKVIE and Screens dirs. were needed. The others were not. Not sure what you mean by not needed. However, you don't save anything by not just copying trunk to tag. Since svn uses cheap copies copying the full trunk folder doesn't take any more space than copying certain folders. Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? Our repo structure is as follows: Csvn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX Control/ Docs/ MKVIE/ Screens/ sem_modbus/ Q2. Are we better off using release branches instead of copying to /tags? To svn a copy is a copy. tags and branches are semantic names. In general a tag isn't ever committed to. But, this is only by convention. Q3. Sometime down the line, if I had to re-create a view of Release 1.6, do I just base my workspace on what's in /tags/release-1.6? Or is there another/better way of re-creating a prior release? I would copy the tag to a branch and work from the branch. Q4. I was also expecting /tags to contain just the new files for Release 1.6. However, that wouldn't be case, right? I have a feeling I am confusing myself over nothing. Basically, all a copy is, is a pointer to the location that it copied. So, the state of the path you copy to includes everything from the source path. But, once again, it is a cheap copy so no files are really copied. BOb
RE: SVN Tag / Branch question
Bob, You are correct in making the statement below. However, what's confusing is that when I copied the Docs directory from /trunk to /tags/release-1.6, the directory included files from the previous release also. Basically, I was expecting to see just the new files. I am trying to understand how that happened and how to prevent. Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, October 30, 2012 11:36 AM To: Ahmed, Omair (GE Oil Gas); users@subversion.apache.org Subject: RE: SVN Tag / Branch question Hello, We did our first release in SVN today. I used the copy command (shown below) to copy from /trunk to /tag. Since not everything in /trunk was needed for this release, I had to specify the directories which were needed. Q1. Is this the normal/correct way of doing things? For the new release, just the Docs, MKVIE and Screens dirs. were needed. The others were not. Not sure what you mean by not needed. However, you don't save anything by not just copying trunk to tag. Since svn uses cheap copies copying the full trunk folder doesn't take any more space than copying certain folders. Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? Our repo structure is as follows: Csvn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX Control/ Docs/ MKVIE/ Screens/ sem_modbus/ Q2. Are we better off using release branches instead of copying to /tags? To svn a copy is a copy. tags and branches are semantic names. In general a tag isn't ever committed to. But, this is only by convention. Q3. Sometime down the line, if I had to re-create a view of Release 1.6, do I just base my workspace on what's in /tags/release-1.6? Or is there another/better way of re-creating a prior release? I would copy the tag to a branch and work from the branch. Q4. I was also expecting /tags to contain just the new files for Release 1.6. However, that wouldn't be case, right? I have a feeling I am confusing myself over nothing. Basically, all a copy is, is a pointer to the location that it copied. So, the state of the path you copy to includes everything from the source path. But, once again, it is a cheap copy so no files are really copied. BOb
Re: SVN Tag / Branch question
On Tue, Oct 30, 2012 at 1:10 PM, Ahmed, Omair (GE Oil Gas) omair.ah...@ge.com wrote: However, what's confusing is that when I copied the Docs directory from /trunk to /tags/release-1.6, the directory included files from the previous release also. Basically, I was expecting to see just the new files. I am trying to understand how that happened and how to prevent. You should get whatever is in the source of the copy (/trunk) at that revision. If there are files that no longer belong there in the current work, delete them. You'll still be able to recover them easily from the release tag that contained them and even (slightly less easily) by using peg-revision syntax to specify a revision where they existed. -- Les Mikesell lesmikes...@gmail.com
RE: SVN Tag / Branch question
You are correct in making the statement below. However, what's confusing is that when I copied the Docs directory from /trunk to /tags/release-1.6, the directory included files from the previous release also. Basically, I was expecting to see just the new files. I am trying to understand how that happened and how to prevent. I think perhaps you have a misunderstanding of how subversion revisions work. A revision contains ALL of the files in the path no matter what previous rev they were last changed in. Do you have different files in the same path that apply to different releases? If so, I think you are doing something wrong. For example, you should have... readme_v1.txt and then make a readme_v2.txt for a new release. You should just modify the readme.txt file accordingly and let svn keep track of which rev of that file goes with which release of your product. You should go and review Chapter 1 and 2 of the documentation. http://svnbook.red-bean.com/en/1.7/svn-book.html BOb Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, October 30, 2012 11:36 AM To: Ahmed, Omair (GE Oil Gas); users@subversion.apache.org Subject: RE: SVN Tag / Branch question Hello, We did our first release in SVN today. I used the copy command (shown below) to copy from /trunk to /tag. Since not everything in /trunk was needed for this release, I had to specify the directories which were needed. Q1. Is this the normal/correct way of doing things? For the new release, just the Docs, MKVIE and Screens dirs. were needed. The others were not. Not sure what you mean by not needed. However, you don't save anything by not just copying trunk to tag. Since svn uses cheap copies copying the full trunk folder doesn't take any more space than copying certain folders. Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? Our repo structure is as follows: Csvn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX Control/ Docs/ MKVIE/ Screens/ sem_modbus/ Q2. Are we better off using release branches instead of copying to /tags? To svn a copy is a copy. tags and branches are semantic names. In general a tag isn't ever committed to. But, this is only by convention. Q3. Sometime down the line, if I had to re-create a view of Release 1.6, do I just base my workspace on what's in /tags/release-1.6? Or is there another/better way of re-creating a prior release? I would copy the tag to a branch and work from the branch. Q4. I was also expecting /tags to contain just the new files for Release 1.6. However, that wouldn't be case, right? I have a feeling I am confusing myself over nothing. Basically, all a copy is, is a pointer to the location that it copied. So, the state of the path you copy to includes everything from the source path. But, once again, it is a cheap copy so no files are really copied. BOb
RE: SVN Tag / Branch question
-Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, October 30, 2012 2:41 PM To: Ahmed, Omair (GE Oil Gas); users@subversion.apache.org Subject: RE: SVN Tag / Branch question You are correct in making the statement below. However, what's confusing is that when I copied the Docs directory from /trunk to /tags/release-1.6, the directory included files from the previous release also. Basically, I was expecting to see just the new files. I am trying to understand how that happened and how to prevent. I think perhaps you have a misunderstanding of how subversion revisions work. A revision contains ALL of the files in the path no matter what previous rev they were last changed in. Do you have different files in the same path that apply to different releases? If so, I think you are doing something wrong. For example, you should have... Sorry, the above should say: For example, you should NOT have... readme_v1.txt and then make a readme_v2.txt for a new release. You should just modify the readme.txt file accordingly and let svn keep track of which rev of that file goes with which release of your product. You should go and review Chapter 1 and 2 of the documentation. http://svnbook.red-bean.com/en/1.7/svn-book.html BOb Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, October 30, 2012 11:36 AM To: Ahmed, Omair (GE Oil Gas); users@subversion.apache.org Subject: RE: SVN Tag / Branch question Hello, We did our first release in SVN today. I used the copy command (shown below) to copy from /trunk to /tag. Since not everything in /trunk was needed for this release, I had to specify the directories which were needed. Q1. Is this the normal/correct way of doing things? For the new release, just the Docs, MKVIE and Screens dirs. were needed. The others were not. Not sure what you mean by not needed. However, you don't save anything by not just copying trunk to tag. Since svn uses cheap copies copying the full trunk folder doesn't take any more space than copying certain folders. Also, if you released your product from a certain svn revision, aren't ALL the files in that revision part of that release version? Our repo structure is as follows: Csvn list https://X.X.com/svn/muxbopcs_svn/trunk/MUX Control/ Docs/ MKVIE/ Screens/ sem_modbus/ Q2. Are we better off using release branches instead of copying to /tags? To svn a copy is a copy. tags and branches are semantic names. In general a tag isn't ever committed to. But, this is only by convention. Q3. Sometime down the line, if I had to re-create a view of Release 1.6, do I just base my workspace on what's in /tags/release-1.6? Or is there another/better way of re-creating a prior release? I would copy the tag to a branch and work from the branch. Q4. I was also expecting /tags to contain just the new files for Release 1.6. However, that wouldn't be case, right? I have a feeling I am confusing myself over nothing. Basically, all a copy is, is a pointer to the location that it copied. So, the state of the path you copy to includes everything from the source path. But, once again, it is a cheap copy so no files are really copied. BOb
