Merge question
I'm getting back into using Subversion and I'm not sure how to answer a question a co-worker asked me regarding merging. Can someone please explain how the following is handled with the following repository structure of our ASP.NET Intranet site? Our repository is structured below: IntranetSite - Trunk - Branches - Tags Now having all production source code witin the Trunk and development within the Branches, if I'm working on the source of a particular sub-program within the Branches as well as another developer is working a different source file also under the same Branch, I've completed my work and am ready for my changes to be merged back into the Trunk. Is it possible to merge only my changes back into the Trunk? Becuase the other developer is Unit Testing his source files, but he's not ready for his changes to be put into the Trunk yet. I hope this was clear. Thanks.
Re: Merge question
On Thu, Mar 04, 2010 at 02:29:33PM -0500, CoolBreeze wrote: > Now having all production source code witin the Trunk and development within > the Branches, if I'm working on the source of a particular sub-program > within the Branches as well as another developer is working a different > source file also under the same Branch, I've completed my work and am ready > for my changes to be merged back into the Trunk. Is it possible to merge This is a cherry-pick merge. Check out the Merge chapter of the book (or wait for someone less lazy than me to link you to it). tyler
RE: Merge question
> On Thu, Mar 04, 2010 at 02:29:33PM -0500, CoolBreeze wrote: > > Now having all production source code witin the Trunk and development > within > > the Branches, if I'm working on the source of a particular sub-program > > within the Branches as well as another developer is working a different > > source file also under the same Branch, I've completed my work and am > ready > > for my changes to be merged back into the Trunk. Is it possible to merge > > This is a cherry-pick merge. Check out the Merge chapter of the book (or > wait for someone less lazy than me to link you to it). > > tyler http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.cherrypicking BOb
Re: Merge question
On Thu, Mar 04, 2010 at 02:49:53PM -0500, Bob Archer wrote: > http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.cherrypicking Bob is an excellent example of someone less lazy than me :). tyler
Re: Merge question
Ok after having a few more discussions here's a situation that we face frequently. Lets say Bob is working on Trunk\ProjectX\File1 and John is working on Trunk\ProjectX\File3 and Trunk\ProjectX\File7. Now Bob needs to leave early for the day, but his code is not complete, regardless he comits his code, so that it's safe within the repository and gets revision 21. Now John at the end of the day comits his code and gets revision 22. How can a partial merge be done using TortoiseSVN to get John's code, but exclude Bob's due to it not being complete yet? Performing an update would get you revision 22, which in turn would include Bob's code from revision 21. I was looking over the merge options within Tortoise, but I was unable to easily indentify a way of handling this type of situation, if it's even possible to do so. Thanks. On Fri, Mar 5, 2010 at 10:22 AM, Tyler wrote: > I am not the list. > > On Fri, Mar 05, 2010 at 08:45:59AM -0500, CoolBreeze wrote: > > Ok after having a few more discussions here's a situation that we face > > frequently. > > > > Lets say Bob is working on Trunk\ProjectX\File1 and John is working on > > Trunk\ProjectX\File3 and Trunk\ProjectX\File7. Now Bob needs to leave > early > > for the day, but his code is not complete, regardless he comits his code, > so > > that it's safe within the repository and gets revision 21. Now John at > the > > end of the day comits his code and gets revision 22. > > > > How can a partial merge be done using TortoiseSVN to get John's code, but > > exclude Bob's due to it not being complete yet? Performing an update > would > > get you revision 22, which in turn would include Bob's code from revision > > 21. > > > > I was looking over the merge options within Tortoise, but I was unable to > > easily indentify a way of handling this type of situation, if it's even > > possible to do so. > > > > Thanks. > > > > On Thu, Mar 4, 2010 at 4:04 PM, Tyler wrote: > > > > > Try this query again on the list. You'll need to add more detail (what > > > did you try? what is the output?) if you want a good answer. > > > > > > tyler > > > > > > On Thu, Mar 04, 2010 at 02:38:48PM -0500, CoolBreeze wrote: > > > > Thanks I had a look already, but I'm just just not understanding > clearly > > > how > > > > to handle deal with it. I was looking for something more > straightforward > > > on > > > > this particular situatin. > > > > > > > > > > > > On Thu, Mar 4, 2010 at 2:33 PM, Tyler Roscoe > wrote: > > > > > > > > > On Thu, Mar 04, 2010 at 02:29:33PM -0500, CoolBreeze wrote: > > > > > > Now having all production source code witin the Trunk and > development > > > > > within > > > > > > the Branches, if I'm working on the source of a particular > > > sub-program > > > > > > within the Branches as well as another developer is working a > > > different > > > > > > source file also under the same Branch, I've completed my work > and am > > > > > ready > > > > > > for my changes to be merged back into the Trunk. Is it possible > to > > > merge > > > > > > > > > > This is a cherry-pick merge. Check out the Merge chapter of the > book > > > (or > > > > > wait for someone less lazy than me to link you to it). > > > > > > > > > > tyler > > > > > > > > >
RE: Merge question
> Ok after having a few more discussions here's a situation that we face > frequently. > > Lets say Bob is working on Trunk\ProjectX\File1 and John is working on > Trunk\ProjectX\File3 and Trunk\ProjectX\File7. Now Bob needs to leave > early for the day, but his code is not complete, regardless he comits his > code, so that it's safe within the repository and gets revision 21. Now > John at the end of the day comits his code and gets revision 22. > > How can a partial merge be done using TortoiseSVN to get John's code, but > exclude Bob's due to it not being complete yet? Performing an update would > get you revision 22, which in turn would include Bob's code from revision > 21. Um, a merge brings changes from one path to another. You may not fully understand what merge means. however, if you are saying you want to get John's code to say Branches\Stable then you can do a merge and just choose rev 22. However, you really shouldn't let dev check in stuff that isn't done into trunk. Bob should create a branch for the issue he is working on and check into that. Once all his work is completed it can be merged into trunk using --reintegrate and then the issue branch can be deleted. BOb
Re: Merge question
Thanks Bob. I'm trying to get an understanding of how Merge works. I was actually thinking in the case I presented that Bob actually shouldn't be checking his unfinished work into the Trunk until it is finished as you stated and that he should create a Tag to use until it is. Anyway thanks for the clarification! On Fri, Mar 5, 2010 at 1:08 PM, Bob Archer wrote: > > Ok after having a few more discussions here's a situation that we face > > frequently. > > > > Lets say Bob is working on Trunk\ProjectX\File1 and John is working on > > Trunk\ProjectX\File3 and Trunk\ProjectX\File7. Now Bob needs to leave > > early for the day, but his code is not complete, regardless he comits his > > code, so that it's safe within the repository and gets revision 21. Now > > John at the end of the day comits his code and gets revision 22. > > > > How can a partial merge be done using TortoiseSVN to get John's code, but > > exclude Bob's due to it not being complete yet? Performing an update > would > > get you revision 22, which in turn would include Bob's code from revision > > 21. > > Um, a merge brings changes from one path to another. You may not fully > understand what merge means. > > however, if you are saying you want to get John's code to say > Branches\Stable then you can do a merge and just choose rev 22. > > However, you really shouldn't let dev check in stuff that isn't done into > trunk. Bob should create a branch for the issue he is working on and check > into that. Once all his work is completed it can be merged into trunk using > --reintegrate and then the issue branch can be deleted. > > BOb >
RE: Merge question
Probably a branch rather than a tag. Generally by convention you don't want to commit to tags. BOb From: CoolBreeze [mailto:coolbreeze...@googlemail.com] Sent: Friday, March 05, 2010 1:36 PM To: users@subversion.apache.org Subject: Re: Merge question Thanks Bob. I'm trying to get an understanding of how Merge works. I was actually thinking in the case I presented that Bob actually shouldn't be checking his unfinished work into the Trunk until it is finished as you stated and that he should create a Tag to use until it is. Anyway thanks for the clarification! On Fri, Mar 5, 2010 at 1:08 PM, Bob Archer mailto:bob.arc...@amsi.com>> wrote: > Ok after having a few more discussions here's a situation that we face > frequently. > > Lets say Bob is working on Trunk\ProjectX\File1 and John is working on > Trunk\ProjectX\File3 and Trunk\ProjectX\File7. Now Bob needs to leave > early for the day, but his code is not complete, regardless he comits his > code, so that it's safe within the repository and gets revision 21. Now > John at the end of the day comits his code and gets revision 22. > > How can a partial merge be done using TortoiseSVN to get John's code, but > exclude Bob's due to it not being complete yet? Performing an update would > get you revision 22, which in turn would include Bob's code from revision > 21. Um, a merge brings changes from one path to another. You may not fully understand what merge means. however, if you are saying you want to get John's code to say Branches\Stable then you can do a merge and just choose rev 22. However, you really shouldn't let dev check in stuff that isn't done into trunk. Bob should create a branch for the issue he is working on and check into that. Once all his work is completed it can be merged into trunk using --reintegrate and then the issue branch can be deleted. BOb
Re: Merge question
Again thank you. On Fri, Mar 5, 2010 at 1:47 PM, Bob Archer wrote: > Probably a branch rather than a tag. Generally by convention you don't > want to commit to tags. > > > > BOb > > > > > > *From:* CoolBreeze [mailto:coolbreeze...@googlemail.com] > *Sent:* Friday, March 05, 2010 1:36 PM > *To:* users@subversion.apache.org > *Subject:* Re: Merge question > > > > Thanks Bob. I'm trying to get an understanding of how Merge works. I was > actually thinking in the case I presented that Bob actually shouldn't be > checking his unfinished work into the Trunk until it is finished as you > stated and that he should create a Tag to use until it is. > > > > Anyway thanks for the clarification! > > On Fri, Mar 5, 2010 at 1:08 PM, Bob Archer wrote: > > > Ok after having a few more discussions here's a situation that we face > > frequently. > > > > Lets say Bob is working on Trunk\ProjectX\File1 and John is working on > > Trunk\ProjectX\File3 and Trunk\ProjectX\File7. Now Bob needs to leave > > early for the day, but his code is not complete, regardless he comits his > > code, so that it's safe within the repository and gets revision 21. Now > > John at the end of the day comits his code and gets revision 22. > > > > How can a partial merge be done using TortoiseSVN to get John's code, but > > exclude Bob's due to it not being complete yet? Performing an update > would > > get you revision 22, which in turn would include Bob's code from revision > > 21. > > Um, a merge brings changes from one path to another. You may not fully > understand what merge means. > > however, if you are saying you want to get John's code to say > Branches\Stable then you can do a merge and just choose rev 22. > > However, you really shouldn't let dev check in stuff that isn't done into > trunk. Bob should create a branch for the issue he is working on and check > into that. Once all his work is completed it can be merged into trunk using > --reintegrate and then the issue branch can be deleted. > > BOb > > >
Branch/switch/merge question
I've read the visual guide, the subversion book, I've used subversion for years, but never really collaborated much with other people on actual software source code the way it's intended to be used, until recently. So it's only recently that I'm making use of branch/merge, and I'd like to get the advice of you more experienced svn users, about my usage pattern. In particular, I branch (and switch) from /trunk to /branches/eharvey. I then make a few commits. I switch back to /trunk, and merge from the branch. I commit to trunk. (I'm always at a loss for comment, because I'm just committing things that have already been commented. But that's a side note.) I then switch back to /branches/eharvey, and merge from /trunk. So here's my question: Even if I'm the only person who committed anything... I was fully committed on /branches/eharvey, I then became fully committed on /trunk, and when I merge back into /branches/eharvey, suddenly I'm not fully committed. My latest status (check for modifications) shows the child subfolder as "modified," and when I diff it, it's the svn:mergeinfo property that's different. It shows that I merged /trunk into /branches/eharvey, even though there were no changes from trunk to merge in. So, most importantly, am I using svn branch/switch/merge in the way that it's intended to be used? Is this the normal, expected, and desired behavior, and I should just get used to it? Should my usage pattern be different somehow?
RE: Branch/switch/merge question
> From: Edward Ned Harvey (svn4) [mailto:s...@nedharvey.com] > Sent: Tuesday, November 26, 2013 9:13 AM > To: users@subversion.apache.org > Subject: Branch/switch/merge question > > In particular, I branch (and switch) from /trunk to /branches/eharvey. I > then make a few commits. I switch back to /trunk, and merge from the branch. > I commit to trunk. (I'm always at a loss for comment, because I'm just > committing things that have already been commented. But that's a side note.) > I then switch back to /branches/eharvey, and merge from /trunk. > So here's my question: Even if I'm the only person who committed anything... > > I was fully committed on /branches/eharvey, I then became fully committed > on /trunk, and when I merge back into /branches/eharvey, suddenly I'm not > fully committed. My latest status (check for modifications) shows the child > subfolder as "modified," and when I diff it, it's the svn:mergeinfo property > that's different. It shows that I merged /trunk into /branches/eharvey, > even though there were no changes from trunk to merge in. It's a feature. The repository HEAD revision changed, i.e. someone checked in somewhere else in the repository, so svn updates the svn:mergeinfo property anyway. Personally, I wish the merge and merge tools (especially mergeinfo) used the Last Changed Revision instead. > So, most importantly, am I using svn branch/switch/merge in the way that it's > intended to be used? Yes. > Should my usage pattern be different somehow? No, but since you're the only one working on the trunk, you don't necessarily need to branch/merge. However, if you have a continuous integration server that's constantly building and deploying new commits from trunk, then working on the feature branch and only merging when your feature branch is stable is a good thing.
RE: Branch/switch/merge question
> From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] > Sent: Tuesday, November 26, 2013 9:30 AM > > No, but since you're the only one working on the trunk, you don't necessarily > need to branch/merge. Thanks - I'm not the only person working on it. But sometimes I'll have something to merge back into trunk before anyone else has merged anything in. (It's a small group).
RE: Branch/switch/merge question
> I've read the visual guide, the subversion book, I've used subversion for > years, but never really collaborated much with other people on actual > software source code the way it's intended to be used, until recently. So > it's > only recently that I'm making use of branch/merge, and I'd like to get the > advice of you more experienced svn users, about my usage pattern. > > In particular, I branch (and switch) from /trunk to /branches/eharvey. I then > make a few commits. I switch back to /trunk, and merge from the branch. I > commit to trunk. (I'm always at a loss for comment, because I'm just > committing things that have already been commented. But that's a side > note.) I then switch back to /branches/eharvey, and merge from /trunk. > > So here's my question: Even if I'm the only person who committed > anything... I was fully committed on /branches/eharvey, I then became fully > committed on /trunk, and when I merge back into /branches/eharvey, > suddenly I'm not fully committed. My latest status (check for modifications) > shows the child subfolder as "modified," and when I diff it, it's the > svn:mergeinfo property that's different. It shows that I merged /trunk into > /branches/eharvey, even though there were no changes from trunk to > merge in. Are you using svn 1.8? If not, are you doing reintegration merge when merging your branch back in to the trunk? > So, most importantly, am I using svn branch/switch/merge in the way that it's > intended to be used? > Is this the normal, expected, and desired behavior, and I should just get used > to it? > Should my usage pattern be different somehow? Generally, there isn't a reason to branch as a matter of course. It's not wrong per say... but I'd rather see all the work just done in trunk. Branches would be used for larger features that multiple people might collaborate on, or take longer than a day or so. Although, having each developer work only on a branch does facilitate code reviews. You do your work on a branch, someone reviews it, once ok'ed it gets merged to branch. Also, I suggest people avoid using switch. It is too easy to forget which svn path you are currently pointing to and commit something to the wrong path. Also, svn switch doesn't handle non-versioned stuff as well as say GIT does. I'd much rather see our devs check out trunk and branch to separate local working copies. BOb
RE: Branch/switch/merge question
> From: Bob Archer [mailto:bob.arc...@amsi.com] > > Are you using svn 1.8? Oh - uhm... I'm using TortoiseSVN, 1.8.2, which is built against Subversion 1.8.3. > If not, are you doing reintegration merge when merging your branch back in > to the trunk? I'm not familiar with those words. Maybe next time I merge, I'll look for a checkbox or something that says "reintegration." ? If I see it, I don't know what it means... I guess I'll google for svn reintegration merge. > Generally, there isn't a reason to branch as a matter of course. It's not > wrong > per say... but I'd rather see all the work just done in trunk. Branches would > be used for larger features that multiple people might collaborate on, or take > longer than a day or so. The reason we decided to start branching was... As long as we were all (all 3 of us) working on trunk, none of us would commit anything that still caused a compile error, or hadn't been at least tested to be launchable. Nobody wanted to be responsible for blocking the others from actually developing. So we decided to all start branching and doing more frequent commits. The other 2 guys are git fanatics, but I'm the IT person, and I don't want to deal with git for now. Effort into migrating toward git would be effort mal-spent in a tiny startup. If all we want to do is branch & merge, I know svn can handle that. I just want to be sure we're not being idiots in some way cuz none of us has ever done it before (with svn). > Also, I suggest people avoid using switch. It is too easy to forget which svn > path you are currently pointing to and commit something to the wrong path. > Also, svn switch doesn't handle non-versioned stuff as well as say GIT does. > I'd much rather see our devs check out trunk and branch to separate local > working copies. I think you're talking about git stash. Right? And I think you're saying... At first, I was doing a sparse checkout. I non-recursively checked out /, and then I made /trunk fully recursive, and then I went one level deeper into /branches, and then I made /branches/eharvey fully recursive... And then I discovered how natural it was to switch & merge, so I got rid of my whole working copy, and re-checked out recursively (non-sparse) /trunk. But it sounds like you suggest going back to the non-recursive checkout of /, with recursive /trunk, and recursive /branches/eharvey. Just to keep the branch & trunk logically separate from each other and eliminate any user error regarding "Which what, oh, where am I? I forget..." You might be right... and if I say so to the other guys, they might use this to bludgeon me into git. ;-)
Re: Branch/switch/merge question
On Tue, Nov 26, 2013 at 8:02 PM, Edward Ned Harvey (svn4) wrote: > > > At first, I was doing a sparse checkout. I non-recursively checked out /, > and then I made /trunk fully recursive, and then I went one level deeper into > /branches, and then I made /branches/eharvey fully recursive... And then I > discovered how natural it was to switch & merge, so I got rid of my whole > working copy, and re-checked out recursively (non-sparse) /trunk. But it > sounds like you suggest going back to the non-recursive checkout of /, with > recursive /trunk, and recursive /branches/eharvey. Not sure what you mean about with sparse and recursive checkouts or why you'd start with /. If there is one project in the repository you would normally just check out /trunk. Or with multiple projects, /project_name/trunk. > Just to keep the branch & trunk logically separate from each other and > eliminate any user error regarding "Which what, oh, where am I? I forget..." > You might be right... and if I say so to the other guys, they might use > this to bludgeon me into git. ;-) You can have multiple checkouts that don't really affect each other, so yes sometimes it is simpler to just have a parallel checkout of a branch unless there are bandwidth or disk space constraints that make switching more efficient. If your project is large enough to split out libraries that can be developed separately, consider moving them out to project-level directories or separate repositories, and assembling the components you want in the main project with svn externals. Then each component can have its own release scheduling (make tags, then when a project using the component wants to update, change the external to the newer tag). This lets your team work on different parts without too much impact on each other while still being able to build the whole thing easily. -- Les Mikesell lesmikes...@gmail.com
RE: Branch/switch/merge question
> From: Les Mikesell [mailto:lesmikes...@gmail.com] > > Not sure what you mean about with sparse and recursive checkouts or > why you'd start with /. If there is one project in the repository > you would normally just check out /trunk. Or with multiple projects, > /project_name/trunk. ... see below... > You can have multiple checkouts that don't really affect each other, Yes, that's what I'm talking about. I know I can do this: mkdir trunk ; svn co $URL/trunk trunk mkdir eharvey; svn co $URL/branches/eharvey eharvey But I prefer to do this: svn co --depth=immediates $URL svn update --set-depth infinity project/trunk svn update --set-depth immediates project/branches svn update --set-depth infinity project/branches/eharvey Because in the latter "sparse" checkout, all the directories retain some context about the directories around them, and I can issue a single "svn update" at the top level in order to update both, and I won't get confused about the path relation between two independent checkouts, while I'm browsing around my local filesystem, and stuff like that. But as far as branching/merging is concerned, it's functionally equivalent.
Re: Branch/switch/merge question
On Thu, Nov 28, 2013 at 8:51 AM, Edward Ned Harvey (svn4) wrote: > > But I prefer to do this: > svn co --depth=immediates $URL > svn update --set-depth infinity project/trunk > svn update --set-depth immediates project/branches > svn update --set-depth infinity project/branches/eharvey > > Because in the latter "sparse" checkout, all the directories retain some > context about the directories around them, and I can issue a single "svn > update" at the top level in order to update both, and I won't get confused > about the path relation between two independent checkouts, while I'm browsing > around my local filesystem, and stuff like that. > > But as far as branching/merging is concerned, it's functionally equivalent. We just think the opposite way about the relationship. My approach is that the checked out copies are completely independent things and any relationship that might exist is best maintained by separate commit/update cycles and eventual merges - just as it would be if different people were working on the separate copies. What commit log message would ever be appropriate if you commit to both the trunk and branch through an upper level directory that ties them together? -- Les Mikesell lesmikes...@gmail.com
RE: Branch/switch/merge question
> From: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Thursday, November 28, 2013 11:58 AM > > What commit > log message would ever be appropriate if you commit to both the trunk > and branch through an upper level directory that ties them together? I see your point of view. I'm always careful and encourage other people to always be careful to review all their commits before committing. It's very easy, for example, to refactor some variable "e" to "localException" and accidentally muck up all the comments about somebody else's variable "e" and so forth. So it's important to review and ensure what you're actually committing is what you *think* you're committing, before you commit. In other words, "Don't do that." ;-)
Re: UNS: Re: Branch/switch/merge question
On Thu, 28 Nov 2013 10:58:08 +, Les Mikesell wrote: ... > different people were working on the separate copies. What commit > log message would ever be appropriate if you commit to both the trunk > and branch through an upper level directory that ties them together? svn commit -m 'just to confuse the russians' Seriously, -m 'fix #1234' if separate fixes are needed because of code divergence. Occasionally. :-) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
