SVN best practices

[Erick Thompson]

As might be evidenced by my previous posts, I'm bringing an organization
into a better situation with regards to development. In particular, I've
been looking at testing, dev methods, build systems, source control,
work tracking, etc. I've got a handle on most everything, except that I
can see a lot of way that I could shoot myself in the foot in regards to
the SVN structure. Is there a document/FAQ about the best way to set up
SVN?

 

I was planning on something like the following

 

Root

   |--- Project A

          |--- Main

                |--- Feature A

                |--- Feature B

          |--- Release

                |--- Current

                |--- Beta X

                |--- Final

                    |--- Servicing

                         |--- 1.1

                         |--- 1.2

 

This is the way that I would set it up under TFS, and is how I've worked
with branches before. Does this structure work well for SVN, or are
there a different set of considerations?

 

Thanks!

 

Erick

 

 

 

 

 

 



This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this e-mail in error please notify the NBR system manager.  If you are not the named addressee please notify the sender immediately by e-mail and please delete this e-mail from your system.  If you are not the intended recipient you are hereby notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited.

Warning: Although having taken reasonable precautions to ensure no viruses are present in this e-mail, The National Bureau of Asian Research cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments.

[Ian Joyce]

Version Control with Subversion:
http://svnbook.red-bean.com/en/1.5/svn-book.html

--Ian

On Mon, Sep 21, 2009 at 2:54 PM, Erick Thompson <erickt@...> wrote:

>
>
> As might be evidenced by my previous posts, I’m bringing an organization into a better situation with regards to development. In particular, I’ve been looking at testing, dev methods, build systems, source control, work tracking, etc. I’ve got a handle on most everything, except that I can see a lot of way that I could shoot myself in the foot in regards to the SVN structure. Is there a document/FAQ about the best way to set up SVN?
>
>
>
> I was planning on something like the following
>
>
>
> Root
>
>    |--- Project A
>
>           |--- Main
>
>                 |--- Feature A
>
>                 |--- Feature B
>
>           |--- Release
>
>                 |--- Current
>
>                 |--- Beta X
>
>                 |--- Final
>
>                     |--- Servicing
>
>                          |--- 1.1
>
>                          |--- 1.2
>
>
>
> This is the way that I would set it up under TFS, and is how I’ve worked with branches before. Does this structure work well for SVN, or are there a different set of considerations?
>
>
>
> Thanks!
>
>
>
> Erick
>
>
>
>
>
>
>
>
>
>
>
>
>
> This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the NBR system manager. If you are not the named addressee please notify the sender immediately by e-mail and please delete this e-mail from your system. If you are not the intended recipient you are hereby notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited.
>
> Warning: Although having taken reasonable precautions to ensure no viruses are present in this e-mail, The National Bureau of Asian Research cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments.
>
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/altdotnet/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/altdotnet/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:altdotnet-digest@...
    mailto:altdotnet-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    altdotnet-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Erick Thompson]

I now realize how different TFS and SVN are. In TFS, when you move code from a feature branch (branch in SVN parlance) to main (trunk in SVN), you forward integrate, as the feature branch is a child of the main branch. In SVN, they are peers, so I assume that you do a merge (cross integrate in TFS terms) to move code from a feature branch to the main branch. Is this approx correct?

The tag branch is easy - it's just a releases branch with an odd name. :)

Thanks,
Erick


-----Original Message-----
From: altdotnet@... [mailto:altdotnet@...] On Behalf Of Ian Joyce
Sent: Monday, September 21, 2009 1:02 PM
To: altdotnet@...
Subject: Re: [altdotnet] SVN best practices

Version Control with Subversion:
http://svnbook.red-bean.com/en/1.5/svn-book.html

--Ian

On Mon, Sep 21, 2009 at 2:54 PM, Erick Thompson <erickt@...> wrote:

>
>
> As might be evidenced by my previous posts, I'm bringing an organization into a better situation with regards to development. In particular, I've been looking at testing, dev methods, build systems, source control, work tracking, etc. I've got a handle on most everything, except that I can see a lot of way that I could shoot myself in the foot in regards to the SVN structure. Is there a document/FAQ about the best way to set up SVN?
>
>
>
> I was planning on something like the following
>
>
>
> Root
>
>    |--- Project A
>
>           |--- Main
>
>                 |--- Feature A
>
>                 |--- Feature B
>
>           |--- Release
>
>                 |--- Current
>
>                 |--- Beta X
>
>                 |--- Final
>
>                     |--- Servicing
>
>                          |--- 1.1
>
>                          |--- 1.2
>
>
>
> This is the way that I would set it up under TFS, and is how I've worked with branches before. Does this structure work well for SVN, or are there a different set of considerations?
>
>
>
> Thanks!
>
>
>
> Erick
>
>
>
>
>
>
>
>
>
>
>
>
>
> This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the NBR system manager. If you are not the named addressee please notify the sender immediately by e-mail and please delete this e-mail from your system. If you are not the intended recipient you are hereby notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited.
>
> Warning: Although having taken reasonable precautions to ensure no viruses are present in this e-mail, The National Bureau of Asian Research cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments.
>
>

------------------------------------

Yahoo! Groups Links

[Kennedy, Noel]

I don't know the TFS semantics/implementation but something you should be aware of in SVN is there is a big difference between merge and re-integrate, something I unfortunately found out the hard way!

Someone please correct me if I've got it wrong but, to generalise (true as of svn 1.5 and as far as I have managed to discover, later versions):

 - To synchronise changes from the trunk into a feature branch, you merge.
 - To synchronise changes from a feature branch into the trunk, you re-integrate.  

Merging and re-integration appear to be similar operations but are actually implemented in very different ways, and if you treat them the same, well, lets just say its not the end of the world but I can save you some time!  This is my understanding of : http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

Merge

Although feature branches + the trunk are peers, there is meta data (called mergeinfo) attached to the feature branch which facilitates merging from the trunk.  This means that commits to the trunk, once merged to the branch, aren't re-merged during a later merge attempt.  Another way to put this is, a feature branch records which revisions have been merged into it.

Reintegrate

When a feature branch is ready for release into the trunk, you re-integrate it.  This has a completely different mechanism from merge.  For it to work, you must ensure all changes in the trunk are merged into the branch.  Anything that has not been merged, will be overwritten on reintegration (As I understand it!). Reintegrate, although it appears to be semantically the same as merging, actually instructs SVN to.

Find out all the differences between my feature branch and the trunk, apply those changes to this working copy of the trunk on my hard drive.

You can then ensure its all working in your working copy, (it should do, you did merge the trunk into the branch and test it there didn't you!) and commit.  The trunk and the feature branch are now identical, ie your feature is in the trunk.  

You should now delete your feature branch. Why!?!  Because of that mergeinfo. If you try to merge further changes from the trunk into your reintegrated feature branch, there will be no record of your reintegration commit being merged into the feature branch.  Head spinning yet?  The reintegration is a commit to the trunk like any other, you will end up with a world of tree conflict pain as you have, in essence, asked SVN to bundle up all the changes from your feature branch and reapply them. "Svn, i want you to create a file called 'root/branch/allgonewrong/woops.cs', and then create a file called 'root/branch/allgonewrong/woops.cs'".  

There is a way around this which keeps the feature branch alive. Very briefly, you fake a merge from the trunk to the branch, so that it appears that your re-integration commit into the trunk has already been merged into the branch and therefore does not need to be merged again.  

Hope this helps!

Cheers,

Noel Kennedy


Original Message-----
From: altdotnet@... on behalf of Erick Thompson
Sent: Mon 21/09/2009 21:31
To: altdotnet@...
Subject: RE: [altdotnet] SVN best practices

I now realize how different TFS and SVN are. In TFS, when you move code from a feature branch (branch in SVN parlance) to main (trunk in SVN), you forward integrate, as the feature branch is a child of the main branch. In SVN, they are peers, so I assume that you do a merge (cross integrate in TFS terms) to move code from a feature branch to the main branch. Is this approx correct?

The tag branch is easy - it's just a releases branch with an odd name. :)

Thanks,
Erick


-----Original Message-----
From: altdotnet@... [mailto:altdotnet@...] On Behalf Of Ian Joyce
Sent: Monday, September 21, 2009 1:02 PM
To: altdotnet@...
Subject: Re: [altdotnet] SVN best practices

Version Control with Subversion:
http://svnbook.red-bean.com/en/1.5/svn-book.html

--Ian

On Mon, Sep 21, 2009 at 2:54 PM, Erick Thompson <erickt@...> wrote:

>
>
> As might be evidenced by my previous posts, I'm bringing an organization into a better situation with regards to development. In particular, I've been looking at testing, dev methods, build systems, source control, work tracking, etc. I've got a handle on most everything, except that I can see a lot of way that I could shoot myself in the foot in regards to the SVN structure. Is there a document/FAQ about the best way to set up SVN?
>
>
>
> I was planning on something like the following
>
>
>
> Root
>
>    |--- Project A
>
>           |--- Main
>
>                 |--- Feature A
>
>                 |--- Feature B
>
>           |--- Release
>
>                 |--- Current
>
>                 |--- Beta X
>
>                 |--- Final
>
>                     |--- Servicing
>
>                          |--- 1.1
>
>                          |--- 1.2
>
>
>
> This is the way that I would set it up under TFS, and is how I've worked with branches before. Does this structure work well for SVN, or are there a different set of considerations?
>
>
>
> Thanks!
>
>
>
> Erick
>
>
>
>
>
>
>
>
>
>
>
>
>
> This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the NBR system manager. If you are not the named addressee please notify the sender immediately by e-mail and please delete this e-mail from your system. If you are not the intended recipient you are hereby notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited.
>
> Warning: Although having taken reasonable precautions to ensure no viruses are present in this e-mail, The National Bureau of Asian Research cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments.
>
>

------------------------------------

Yahoo! Groups Links







 

[Adam Dymitruk]

A best practice for SVN is to move to GIT :P

--
Adam

http://adventuresinagile.blogspot.com/
http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvancouver.ning.com/

[Erick Thompson]

Ok, given that we've moved 70% of the way down the SVN path, how much
pain am I going to be in for if I move us to GIT in a year or two? Am I
going to lose all my histories, changelists, etc?

 

Thanks,

Erick

 

From: altdotnet@... [mailto:altdotnet@...] On
Behalf Of Adam Dymitruk
Sent: Monday, September 21, 2009 3:34 PM
To: altdotnet@...
Subject: Re: [altdotnet] SVN best practices

 

 

A best practice for SVN is to move to GIT :P

--
Adam

http://adventuresinagile.blogspot.com/
http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvancouver.ning.com/





This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this e-mail in error please notify the NBR system manager.  If you are not the named addressee please notify the sender immediately by e-mail and please delete this e-mail from your system.  If you are not the intended recipient you are hereby notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited.

Warning: Although having taken reasonable precautions to ensure no viruses are present in this e-mail, The National Bureau of Asian Research cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments.

[Adam Dymitruk]

Let's just say that moving history is not easy especially if you don't
have a standard SVN structure. It will be harder and harder to move
your history the longer you use SVN. You may have to resort to making
patches for every revision and playing them back to make a new GIT
repo.. or any other snapshot-based (and hence superior) SCM tool.

What do you mean you have moved 70% down the SVN path? Does this mean
that 30% of the staff is still using something else still?

> Ok, given that we’ve moved 70% of the way down the SVN path, how much pain am I going to be in for if I move us to GIT in a year or two? Am I going to lose all my histories, changelists, etc?
>
> Thanks,
>
> Erick

--
Adam

http://adventuresinagile.blogspot.com/
http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvancouver.ning.com/


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/altdotnet/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/altdotnet/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:altdotnet-digest@...
    mailto:altdotnet-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    altdotnet-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[ignu]

I just opened this thread to make sure someone said "move to git"

On Mon, Sep 21, 2009 at 7:26 PM, Adam Dymitruk <adam@...> wrote:

> Let's just say that moving history is not easy especially if you don't
> have a standard SVN structure. It will be harder and harder to move
> your history the longer you use SVN. You may have to resort to making
> patches for every revision and playing them back to make a new GIT
> repo.. or any other snapshot-based (and hence superior) SCM tool.
>
> What do you mean you have moved 70% down the SVN path? Does this mean
> that 30% of the staff is still using something else still?
>
> > Ok, given that we’ve moved 70% of the way down the SVN path, how much
> pain am I going to be in for if I move us to GIT in a year or two? Am I
> going to lose all my histories, changelists, etc?
> >
> > Thanks,
> >
> > Erick
>
> --
> Adam
>
> http://adventuresinagile.blogspot.com/
> http://twitter.com/adymitruk/
> http://www.agilevancouver.net/
> http://altnetvancouver.ning.com/
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Adam Dymitruk]

Have you seen this? http://code.google.com/p/gitextensions/

No more excuses :)

Adam

http://adventuresinagile.blogspot.com/
http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvancouver.ning.com/

On Mon, Sep 21, 2009 at 4:18 PM, Erick Thompson <erickt@...> wrote:
>
> Ok, given that we’ve moved 70% of the way down the SVN path, how much pain am I going to be in for if I move us to GIT in a year or two? Am I going to lose all my histories, changelists, etc?
>
> Thanks,
>
> Erick


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/altdotnet/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/altdotnet/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:altdotnet-digest@...
    mailto:altdotnet-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    altdotnet-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Erick Thompson]

Wow, this should be way more well known!

I'm going to take the plunge....

Erick


-----Original Message-----
From: altdotnet@... [mailto:altdotnet@...] On
Behalf Of Adam Dymitruk
Sent: Tuesday, September 22, 2009 11:45 AM
To: altdotnet@...
Subject: Re: [altdotnet] SVN best practices

Have you seen this? http://code.google.com/p/gitextensions/

No more excuses :)

Adam

http://adventuresinagile.blogspot.com/
http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvancouver.ning.com/

On Mon, Sep 21, 2009 at 4:18 PM, Erick Thompson <erickt@...> wrote:
>
> Ok, given that we've moved 70% of the way down the SVN path, how much
pain am I going to be in for if I move us to GIT in a year or two? Am I
going to lose all my histories, changelists, etc?
>
> Thanks,
>
> Erick


------------------------------------

Yahoo! Groups Links





This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this e-mail in error please notify the NBR system manager.  If you are not the named addressee please notify the sender immediately by e-mail and please delete this e-mail from your system.  If you are not the intended recipient you are hereby notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited.

Warning: Although having taken reasonable precautions to ensure no viruses are present in this e-mail, The National Bureau of Asian Research cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments.

[Adam Dymitruk]

Glad to see the transition from SVN to GIT

On Tue, Sep 22, 2009 at 6:23 PM, Erick Thompson <erickt@...> wrote:

>
>
> Wow, this should be way more well known!
>
> I'm going to take the plunge....
>
> Erick
>
>
> -----Original Message-----
> From: altdotnet@... <altdotnet%40yahoogroups.com> [mailto:
> altdotnet@... <altdotnet%40yahoogroups.com>] On
> Behalf Of Adam Dymitruk
> Sent: Tuesday, September 22, 2009 11:45 AM
> To: altdotnet@... <altdotnet%40yahoogroups.com>
> Subject: Re: [altdotnet] SVN best practices
>
> Have you seen this? http://code.google.com/p/gitextensions/
>
> No more excuses :)
>
> Adam
>
> http://adventuresinagile.blogspot.com/
> http://twitter.com/adymitruk/
> http://www.agilevancouver.net/
> http://altnetvancouver.ning.com/
>
> On Mon, Sep 21, 2009 at 4:18 PM, Erick Thompson <erickt@...<erickt%40nbr.org>>
> wrote:
> >
> > Ok, given that we've moved 70% of the way down the SVN path, how much
> pain am I going to be in for if I move us to GIT in a year or two? Am I
> going to lose all my histories, changelists, etc?
> >
> > Thanks,
> >
> > Erick
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this e-mail in error please notify the NBR system
> manager. If you are not the named addressee please notify the sender
> immediately by e-mail and please delete this e-mail from your system. If you
> are not the intended recipient you are hereby notified that disclosing,
> copying, distributing, or taking any action in reliance on the contents of
> this information is strictly prohibited.
>
> Warning: Although having taken reasonable precautions to ensure no viruses
> are present in this e-mail, The National Bureau of Asian Research cannot
> accept responsibility for any loss or damage arising from the use of this
> e-mail or attachments.
>
>  
>

--
Adam

http://adventuresinagile.blogspot.com/
http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://altnetvancouver.ning.com/