subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ahmed, Omair (GE Oil & Gas)" <omair.ah...@ge.com>
Subject RE: SVN Tag / Branch question
Date Tue, 30 Oct 2012 18:10:07 GMT
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.Archer@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




Mime
View raw message