> -----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: > > > > > > C>svn 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 > > > >
