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: 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) s...@nedharvey.com 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: 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 torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Branch/switch/merge question
On Tue, Nov 26, 2013 at 8:02 PM, Edward Ned Harvey (svn4) s...@nedharvey.com 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: 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. ;-)
