[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: SVN Tag / Branch question

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Tue, 30 Oct 2012 14:42:31 -0400

> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
> Sent: Tuesday, October 30, 2012 2:41 PM
> To: Ahmed, Omair (GE Oil & Gas); users_at_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.Archer_at_amsi.com]
> > Sent: Tuesday, October 30, 2012 11:36 AM
> > To: Ahmed, Omair (GE Oil & Gas); users_at_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
> >
> >
Received on 2012-10-30 19:43:05 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.