sparse checkout tool
I remember reading about a tool that let you define what parts of a repository were needed to create a work space. It basically did a bunch of sparse checkouts based on a config file. Could someone remind me what was its name? Please reply directly as I'm no longer on the list. Thanks JLM
undo a switch
Please tell me there's a way to undo a 'svn switch' I tracked down an old working copy for an engineer that had moved on long ago because he had done some work that had never gotten checked in. The view was hopelessly out of date so I did svn copy -r svn://svn/zcode/trunk svn://svn/zcode/branches/jlm_temp1 svn switch svn://svn/zcode/branches/jlm_temp1 where xxx was (I thought) the revision of his view. I thought this would give me a quick way to check in his work just as I found it. But when I did the switch, I got conflicts, so I'm guessing I got the revision wrong. SO...is there a way to get back? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
post-commit notify scripts
I use a post commit script to send email to a list whenever anyone commits anything. I want to start filtering that now. Anyone done this and willing to share any tools? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/>
RE: svn merge --reintegration.
A merge to a new branch based on the head of trunk should be no different than a merge to trunk itself. The secondary merge of the newly merged branch to trunk will be trivial. I still often do exactly what you propose so that I can test and debug the merged code before committing it to trunk. So the real question is, merge from trunk to branch first or just merge from branch to trunk and be done with it? I usually decide based on two things. Is the branch obsolete after this operation? If so, I merge from branch to trunk. If not, I ask myself which changes am I more familiar with and I merge FROM there. For some reason I find this easier. If the merge is painful due to conflicts, I sometimes do the merge one changeset at a time. Have you figured out whether or not the conflicts are due to white space issues such as new lines/carriage returns, tabs/spaces or other reformatting issues? jlm
RE: Choosing a server
I control the subversion server and the servers that host the working copies. If the working copies are elsewhere, my point is irrelevant. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: Gary [mailto:subversion-u...@garydjones.name] > Sent: Friday, September 17, 2010 2:19 AM > To: users@subversion.apache.org > Subject: Re: Choosing a server > > Jeremy Mordkoff wrote: > > Are you hosting the server only, or will you also be hosting working > > copies? Spread working copies across spindles and put the server on its > > own spindle to reduce latency. > > Maybe I don't understand you, but (obviously, I thought) the working > copies will be local to the small number of users who will be using > subversion.
RE: To branch or not to branch unique projects started from a common code set
You need to think about your build process and software architecture and then design your branching strategy to support it. For instance, if you find a bug in the base code, how are you going to get that fix out to all of your customers? One solution is to develop your base code as one project, and then for each customer, treat the base code as a vendor branch, where you accept updates from the base project and merge them into each customers area. The biggest downside is that it will be real easy to make a fix in a customer area that really should have been in the common area. This assumes that there is significant overlap between your base code and the custom code. If the architecture is such that the custom code layers on top of the base code but never changes it, then there are probably two projects. A 'release' would then be a base build plus a custom build. Then the big question is there common customer code. Is there a base class from which all customer code is derived? You need to think about your build process and software architecture and then design your branching strategy to support it. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
RE: Choosing a server
Are you hosting the server only, or will you also be hosting working copies? Spread working copies across spindles and put the server on its own spindle to reduce latency. JLM
RE: Web development development process
What's wrong with using working copies for production? We did configure apache to reject any request with .svn in the url. It means that my deployment vehicle is a simple 'svn co' or 'svn switch'. No messing around with packaging up the files, etc. And this really comes in handy when an update goes bad and I need to revert quick. Plus all I have to do to release to QA is give them the branch and revision. I can check that nobody has messed with anything on the production server with a simple 'svn status'. And I can revert any such change (or commit it if I made it :) ) I even have /etc under svn now :) Makes it very easy to deploy new servers. I request a new hardware unit and the hosting company installs the OS. I install some ssh keys and install/update a handful of packages, do a couple svn co's and update public DNS and I'm up and running. JLM Jeremy L. Mordkoff
RE: subversion configuration problem
On the windows servers, open a command prompt and run 'netstat -n -a' You should see a line something like TCP 0.0.0.0:3690 0.0.0.0:0 listening If it is not there, the server is not running or it is running on the wrong port. If it is there, you have a routing or firewall issue You can also try 'telnet 127.0.0.1 3690' right on the server JLM
RE: subversion configuration problem
Can you ping it by name? by address? Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/>
RE: subversion configuration problem
Have you checked your firewall settings on the Windoze server? Can you telnet to the SVN port from the client? jlm Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/> From: Kayhan Yüksel [mailto:kayh...@fasdat.com.tr] Sent: Wednesday, September 15, 2010 8:09 AM To: users@subversion.apache.org Cc: İsmail Hakkı ŞAHİN Subject: subversion configuration problem To whom it may respond to, We have been required to setup a svn server without using Apache Server on a Windows 2008 Server. After installing SlikSVN , we have created a test repository using svnadmin at c:\svn\repos and started SVNSERVE as deamon. As a client, we are testing AnkhSVN inside VS 2010 , but couldn't connect using svn://machinename/svn/repos , after opening the svn folder to sharing, we have been able to reach via file://machinename/svn/repos , but this is not a good method to live with. How can we setup slikSVN + AnkhSVN to use svn protocol for communications ? Thank you for your concern, Best Regards, Kayhan YÜKSEL FASDAT GIDA A.Ş. IT Department Software Developer __ Information from ESET NOD32 Antivirus, version of virus signature database 5452 (20100915) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
RE: Web development development process
> From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] > > We are not a wed design company but we do have a web service team for our Intranet and > Extranet. They have been working, so far with basically a trunk and no branches or tags. So, > we are thinking of reorganising the repository, with the usual trunk/branches/tags. > > Developers will create branches for everything, nothing will be directly developed in trunk, > i.e. trunk will get changed only by reintegrating branches. Is this reasonable? yes > > Tags will be created from trunk but not necessarely always from the HEAD revision. Is this > reasonable? Yes > > They will have one or more staging areas, which will be a WC of a specific tag, for testing. > The Live area will also be a WC of a specific tags. Only the release manager will be able to > switch the staging and Live areas. Is this reasonable? Not sure about staging areas. The live area should belong to operations. > > One of the developers who is working with me (I'm the SVN admin here) on this reorganisation > presented me with a scenario which I'm not sure how to implement. > > Let's supposed that Live is pointing to tag 1.1, and the staging area is pointing to tag 1.2. > Work is going on in branches and trunk does already contain some changes that will released > (tagged) in 1.3. At this point, however, something extremely urgent comes up that need to be > released in Live as soon as possible. How can we do that? > > My idea would be to create a branch from 1.1 tag (the one is in Live), made the change (let's > say committed in revision 1234), and tag it as 1.1.1. Using a stage are to test tag 1.1.1 and > then switch Live to 1.1.1. These changes will need to be done in trunk too, which I think I > can do with a simple merge. This will be agains what I said earlier but it's a special case. A process is only as good as how it works under stress, so don't consider this a special case. This is a quite reasonable approach. > > My next problem however is the current 1.2 tag. It does not have the changes in revision > 1234, so basically the test I'm doing on the staging area is useless, as I could never > release it. I would need to somehow, create a new 1.2.1 tags, as a copy of 1.2 plus the > changes in revision 1234. Yes. I would have a rel 1.1 branch and a rel 1.2 branch. I would merge from rel 1.1 to rel 1.2 to trunk. I would tag each branch whenever I did a release. > > Is all this a correct way to proceed? I'm sure other people have come across a problem > similar to this, and I would really appreciate any input on how to implement such process. Basically, yes. Now, can anyone point me to a bug tracking system that could capture this? E.g. is there a system That could tell me "found in 1.0, fixed in 1.1, 2.1 and 3.0"?
RE: Two trunks in one repository?
On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek wrote: So the concepts of trunks, branches, tags are transparent to SVN. We are in a situation where we might need to have two trunks in one SVN repository. The reason is that we have a family of projects - say ProjectA, ProjectB, ProjectC and so on, each one has it's own repository and have just one trunk (normal setup) since the each of these project has just one part. But now let's say we have a ProjectD which has two sub-systems - PartA and PartB whose code is 95% different. So we are thinking to have two trunks inside the ProjectD repository. We would prefer not to create an individual repository for PartA and PartB because we have decided to categorize each of the repository based on the family of Projects - ProjectA, ProjectB, ProjectC, ProjectD. Just wanted to know to get some thoughts from the experts on this mailing list regarding this setup. Any gotachs I need to watch out for? Thanks! === Maybe I missed something in your scenario, but I would simply have one trunk with PartA and PartB as sub-directories. === That would depend mostly on your branch and merge patterns. I have a similar situation. Since every branch has both projects in it, every workspace that I use to do merges has to check out both projects, even though no merge ever contains changes to both projects. Quite a pain in the rear. To make it worse, the unix developers use filenames that cannot be created on a windows system (e.g. AUX, COM1, and COM4), so we can't do merges on windows systems at all. At my top level I have code, vendors and tools. 'code' contains all of our code, the other two are for imports. So instead of /code/trunk/proj1 and /code/trunk/proj2, I should have /code/proj1/trunk and /code/proj2/trunk. Then I could branch and merge each project separately. But before I do this, I should make absolutelty sure that these two projects have no interdependencies. AFAIK, branches are just names. So above and beyond fixing up your mergeinfo's (if you have any), this should work just fine. JLM
RE: Renaming a branch
> > Is there a safe way to rename a branch? I'm worried about all > > my mergeinfo's > > If you have merged only from trunk and haven't merged from this branch, I don't see a problem > in using s imple svn mv. > I wish it was that simple branches/rel_2_5_3 merges to branches/rel_2_5 which merges to trunk I want to rename rel_2_5 to rel_2_6
Renaming a branch
Is there a safe way to rename a branch? I'm worried about all my mergeinfo's
RE: hint of the day
The attached archive has 3 files in it BRANCHES is the key file. It lives in the root of trunk. BRANCHES lists all known branches and where they should be merged to. Project branches should have two entries, one "out" to make sure the project branch is staying up to date, and one "in" to make sure that the project merges to somewhere useful someday. There are comments and examples in BRANCHES. changes is a script that checks for all commits since the last time it was run and categorizes them by branch and component (any directory under trunk is a component). It emits a warning if I finds a branch not listed in BRANCHES. tomerge is a script that reminds you of what needs to be merged and from where to where. I run changes and tomerge -c every morning. The path to the repository is hardcoded, as is the location of a workspace. I'd be open to any ideas as to how these could be calculated. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/> From: Erik Andersson [mailto:kir...@gmail.com] Sent: Wednesday, September 01, 2010 8:54 AM To: Jeremy Mordkoff Cc: users@subversion.apache.org Subject: Re: hint of the day On Wed, Sep 1, 2010 at 2:11 PM, Jeremy Mordkoff wrote: Just an FYI for anyone that does merging. I just spent an hour cleaning up a mess with my mergeinfo's. I missed a hint that I was about to do something really stupid. Here's the merge: [rele...@zaz1 rel_2_5]$ svn merge $B/rel_2_5_3 --- Merging r14352 through r14594 into '.': Ulcast/build/images/nand/root/lcast/etc/post_install.sh Ulcast/build/images/nand/root/lcast/etc/lc_UpdateNOR.sh G . [rele...@zaz1 rel_2_5]$ svn commit -m 'merge from rel_2_5_3 of a fix made in trunk' Sending. Sendinglcast/build/images/nand/root/lcast/etc/lc_UpdateNOR.sh Sendinglcast/build/images/nand/root/lcast/etc/post_install.sh Transmitting file data .. Committed revision 14595. The hint I missed was the G next to the '.'. That should have told me that there were changes in my workspace, and since I never knowingly commit local changes and merges at the same time, I should have stopped right there. Also, I have some tools that I use to keep track of branches and stuff. Is there a good place to publish them? I'd like to see them very much. If you don't publish them anywhere, please send them my way. Cheers / Erik JLM svn_tools.tar Description: svn_tools.tar
hint of the day
Just an FYI for anyone that does merging. I just spent an hour cleaning up a mess with my mergeinfo's. I missed a hint that I was about to do something really stupid. Here's the merge: [rele...@zaz1 rel_2_5]$ svn merge $B/rel_2_5_3 --- Merging r14352 through r14594 into '.': Ulcast/build/images/nand/root/lcast/etc/post_install.sh Ulcast/build/images/nand/root/lcast/etc/lc_UpdateNOR.sh G . [rele...@zaz1 rel_2_5]$ svn commit -m 'merge from rel_2_5_3 of a fix made in trunk' Sending. Sendinglcast/build/images/nand/root/lcast/etc/lc_UpdateNOR.sh Sendinglcast/build/images/nand/root/lcast/etc/post_install.sh Transmitting file data .. Committed revision 14595. The hint I missed was the G next to the '.'. That should have told me that there were changes in my workspace, and since I never knowingly commit local changes and merges at the same time, I should have stopped right there. Also, I have some tools that I use to keep track of branches and stuff. Is there a good place to publish them? JLM
RE: commit fails with "has no ancestry information" error (solved)
Thanks for taking the time to post this. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: Neil Brewster [mailto:n...@ajmani.org] On Behalf Of Neil Brewster > Sent: Thursday, August 26, 2010 10:21 AM > To: users@subversion.apache.org > Subject: commit fails with "has no ancestry information" error (solved) > > I've seen this issue reported in various mailing lists without solutions > (including the 2006 archives of this list!). Recently I found an answer > and wanted to add it to the mailing list archives: > > Problem: > > > % svn commit -m '' > > > > I get the following error: > > > > > > svn: '/d0/home/tlm/path_to_some_dir/Project' has no > > ancestry information > > Resolution - > From http://victorhurdugaci.com/svn-no-ancestry-information/: > > It seems that the SVN commit is forbidden if you try to commit a file > that is a folders structure, and one of the nodes in it (not the top most > parent) is missing the .svn folder. > > - folder1 [with .svn] > - folder2 [without .svn] > - folder3 [with .svn] > Committing “folder3″ will bring that error message. > > In my case, there was a stray .svn in folder1 after I rearranged my > workspace. Removing it solved the issue. (SVN client 1.6.6) > > neil.
svndumpfilter and subtrees
I have a repository with multiple projects that used to be branched in parallel, but now need to be split. How do I accomplish this? Current tree zcode/ zcode/trunk/comp1 zcode/trunk/comp2 zcode/branches zcode/branches/rel_1/comp1 zcode/branches/rel_1/comp2 zcode/branches/rel_2/comp1 zcode/branches/rel_2/comp2 except there are actually 11 components, with 8 staying and 3 migrating to a new repository, and there are actually about 25 branches. There are 14,000 commits in our repository. One option (I think) would be to move comp2 to the top using a perl script against the svn dumpfile so that the tree became zcode/ zcode/trunk/comp1 zcode/branches zcode/branches/rel_1/comp1 zcode/branches/rel_2/comp1 ccode/ ccode/trunk ccode/trunk/comp2 ccode/branches ccode/branches/rel_1/comp2 ccode/branches/rel_2/comp2 And then filter on zcode vs ccode: svnadmin create repos/ccode svnadmin dump repos/zcode | perl -p -e 's-Nodepath: zcode/(trunk|(branches|tags)/[^/]+)/comp2-Nodepath: ccode/$1/comp2-;' | svndumpfilter include ccode | svnadmin load repos/ccode svnadmin create repos/zcode2 svnadmin dump repos/zcode | perl -p -e 's-Nodepath: zcode/(trunk|(branches|tags)/[^/]+)/comp2-Nodepath: ccode/$1/comp2-;' | svndumpfilter exclude ccode | svnadmin load repos/zcode2 My concern here is how do directories like /ccode/trunk and /ccode/branches get created? Can a pre-create them in the new repository? I don't care that much about preserving revision numbers in the ccode repo. I cannot simply clone the repos and then selectively delete as the new owners of the new repo could potentially recreate the code from the old repo. Are there any other options? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/>
another mergeinfo question
I have two instances of mergeinfos in the root of my tree showing a wider range of changes merged in than a merge info in a subdirectory. Does svn merge these merge infos together? Example Mergeinfo in /zcode/trunk shows that /zcode/branches/rel_2:1124-1406 was merged Mergeinfo in /zcode/trunk/lcast shows that /zcode/branches/rel_2/lcast:1124-1388 was merged So was 1389-1406 merged in the lcast directory or not? No, I don't know how I got into this state. I wish I had caught this sooner, but rel_2 has been dormant for a while. I suppose I could look at the history of the property. I'm on list now JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
trunk listed in svn:mergeinfo in trunk
Why would trunk be listed in the svn:mergeinfo in trunk? We've been using mergeinfo's for a while now. Could this be the result of merging out (from trunk to a project branch) and then back? Can this safely be deleted? I'm trying to clean up our mergeinfo's because they exist in too many directories and they contain references to literally 2 dozen branches that are long retired and I think they're slowing down my merges which now take almost 5 minutes each. jlm please cc me as I'm still off list
time since last checkin
Anyone got a quick and dirty way to determine how long ago was the last commit? I want to change my build system to not start a build if there was a very recent checkin. That way if someone is checking in a group of changes, I don't end up kicking off a build in the middle and then having to wait for a second build to get the full set of changes. I know most things should be checked in all at once so that they become one change set, but sometimes people have layers of changes and they like to check in the independent part first. Please reply directly...I'm off the list at the moment. jlm Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
RE: multiple ssh connections
Another option is to establish a single SSH session using port mapping and then run all of your SVN traffic across that. Something like ssh -L 3690:svn_server:3690 ssh_server svn svn://localhost/ The first line says take any traffic destined for the svn port on my machine and send it to the svn port on the svn server at the other end of an SSH tunnel. The second line says pretend my svn server is local JLm
RE: Merging branch back to trunk omits dirs and files that were added in the branch
Sounds like the target directories already existed in trunk. How did they get created? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com <mailto:j...@zeevee.com> www.zeevee.com <http://www.zeevee.com/> From: Dean Schulze [mailto:dean_w_schu...@yahoo.com] Sent: Tuesday, June 01, 2010 2:48 PM To: users@subversion.apache.org Subject: Merging branch back to trunk omits dirs and files that were added in the branch I've tried this with both TortoiseSVN and the merge tool that comes with Subclipse. I've added subdirectories with files under several directories on the branch (along with many other changes). When I merge back to the trunk the top level directories under which I added the subdirectories and files show up as tree conflicts. None of the sub-directories or files show up. I mark the tree conflicts as resolved (I mark all tree conflicts as resolved choosing the repository / branch file whenever asked to resolve manually). In the merged trunk the new subdirectories and files are missing all together. The trunk svn:mergeinfo shows the correct range of revisions. What do I have to do to simply merge the branch back to the trunk? Firstly, this is not a conflict of any kind. I added those directories and files intentionally. Secondly, ever since tree conflicts were added to svn I've found svn to be completely unreliable when it comes to merging. How do I turn off tree conflicts (eliminate them all together)? What do I have to do to get back to reliable merging, switch to git?
RE: How to speed up subversion
On 5/24/2010 3:51 PM, David Brodbeck wrote: > > On May 21, 2010, at 8:23 AM, Hyrum K. Wright wrote: >> Actually, Subversion is a bit more intelligent about it, attempting to use >> modification times and sizes, before doing a byte-by-byte comparison. > > Even that can be slow if there are lots of files involved. Note that some > filesystems have particularly bad performance if there are lots of files in a > single directory, as well. This is especially true of NFS. In one extreme > example, I've seen a simple "ls" take tens of minutes to produce any output > in an NFS-mounted directory with ~1,000,000 files. But to be fair, note that ls sorts its output, so it can't output anything until it has read everything. -- Les Mikesell lesmikes...@gmail.com JLM>> unless you use the raw option
detecting merge outs
Here's the situation. We have a release branch that has been around way too long. At one point we did a release from it and around that time it was merged to trunk. There are about 100 commits to it since then. Some were merge outs from trunk, some were changes made directly in the branch. Some of these were merged to trunk, but some were not. Now I need to integrate trunk with the branch. My choices are to merge out from trunk, resolve conflicts and then merge -reintegrate back to trunk, or just merge from the branch to trunk and be done. I am leaning towards the latter. Will the merge outs (from trunk to the branch) cause a problem when I try to merge back in? Does anyone have any advice besides making sure I do the merges in chronological order? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
RE: Is svn branching too difficult?
My rules of thumb for merging (a) always use a fully populated workspace (b) always merge from the top By following these rules, I only get mergeinfo properties in the tops of my workspaces. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: Cufi, Carles [mailto:carles.c...@nordicsemi.no] > Sent: Tuesday, May 18, 2010 10:16 AM > To: Mark Phippard; David Aldrich > Cc: users@subversion.apache.org > Subject: RE: Is svn branching too difficult? > > Hi there, > > > Subversion is likely working properly, but yes it is confusing. When > > you do a merge into a branch, Subversion updates its mergeinfo > > tracking on all of the locations that have the property set. There > > have been numerous posts that describe how and why it gets set in the > > first place. > > Thanks for the info. As I described in an earlier post, I have a trunk and a branch > completely clean of svn:mergeinfo properties and then when I update my branch with the latest > trunk a bunch of svn:mergeinfo properties get added to a sparse set of files. All the posts I > have read ask people to cleanup all svn:mergeinfo in the trunk and then start branching from > it. I have done so but the properties keep reappearing, and this is really confusing for me. > > > Because it is confusing, we have changed how Subversion works in the > > next release. It will not update paths that were not modified by the > > merge, and then Subversion was modified to handle the fact that these > > paths do not get their merge tracking information updated. > > Excellent! Looking forward to that! > > Thanks! > > Carles
RE: Is svn branching too difficult?
Branching and merging is not the simplest operation in the world. Svn is one of the easier environments for doing merging. (a) doing test merges is easy (b) creating branches is easy and quick (c) it does have merge tracking If you had not gotten the 101 property changes, what would your opinion be? Do you have any idea where these property changes came from? JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: David Aldrich [mailto:david.aldr...@eu.nec.com] > Sent: Tuesday, May 18, 2010 9:55 AM > To: users@subversion.apache.org > Subject: Is svn branching too difficult? > > Hi > > I have just finished working on a branch and have performed a reintegrate merge back into the > trunk. I only worked on 4 files in the branch and I carefully merged from trunk to branch > several times (including immediately prior to the reintegration). > > The reintegration correctly identified the four files that I had worked on and that had > changed, but also showed 101 files as 'Modified (properties only)'. I know that there are > good documents that describe merging and explain what this sort of state means, but I > struggle to understand what is going on during merging sometimes. > > I feel unable to recommend branching to my colleagues, it just seems too complicated. I don't > think they would have the time or patience to understand the nuances of merging. > > Do other people feel the same way? Is svn branching too difficult? > > (I am using svn server 1.5.5 and the 1.6.11 client. I wonder if things will be better when we > upgrade the server?) > > This is not meant as a complaint, I am simply trying to judge whether svn branching is > workable. > > With best regards > > David
tracking merges
I know how to find what has been merged into any branch, but is there a tool to track where changes have been merged to? Here's my problem. I was working on a customer release based on rev 5 of our product. Now they have decided to use rev 4 instead. So I need to merge a bunch of changes from the rev 5 branch to the rev 4 branch...actually a new branch based on rev 4. But only their customizations. What I would really like is an option to svn log that would tell me every branch to which each change had been merged, but I'm thinking I'll have to run reports against the potential merge destinations first and then post process the svn log output. Anyone already tackled this? I wish I had just done their customizations in a branch. Thanks JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
RE: Merging a Revision back to the trunk
What command did you use? When was the branch created? At rev 226? jlm Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com > -Original Message- > From: Georg Heisenberger [mailto:heissenberger.ge...@gmx.at] > Sent: Thursday, April 22, 2010 1:13 PM > To: users@subversion.apache.org > Subject: Merging a Revision back to the trunk > > Hi everybody! > > I’ve got a question about merging a revision of an > feature- branch back to the trunk. > Sounds quiet simple: > - Select the branch > - The revision > > ⇒ The changes made in the specific revision should be > applied on my working copy (trunk) > > The “problem” (at least I don’t understand why it’s happening) > is that subversion is merging more than one revision. > > In my case I only want revision 278. > The response of subversion is, that it starts with revision 226 > > > The result: I’ve got more things merged to my WC than I wanted to > > I would be glad, if some can tell me, why that is happening > > Georg >
blocking merges and branches
I have two special files. One I would like never to be merged. The other I would like to only ever exist in trunk. Is there any mechanism to accomplish this? If you careThe file I don't want to merge contains the version numbers for products built in that branch and the un-branchable file is a list of branches that I only want to have in trunk. Currently I do a merge --record-only for the former and live with the latter. JLM Jeremy Mordkoff Director, QA, IT & Release ZeeVee, Inc. One Monarch Drive | Littleton, MA 01460 Office: 978.467.1395 x233 | Fax: 978.467.1404 Mobile: 978-257-2183 j...@zeevee.com www.zeevee.com
RE: Unable to checkout files: Can't open file: Permission denied
did you mean chmod -R 770 myrepository ? -Original Message- From: Disc Magnet [mailto:discmag...@gmail.com] Sent: Tue 4/13/2010 5:27 PM To: Erik Andersson Cc: users@subversion.apache.org Subject: Re: Unable to checkout files: Can't open file: Permission denied I did that. I ran these two commands. chgrp -R www-data myrepository chown -R 770 myrepository Now, I get this error: $ svn commit -m "Updating" svn: Commit failed (details follow): svn: Could not open the requested SVN filesystem Please help. On Wed, Apr 14, 2010 at 1:59 AM, Erik Andersson wrote: > The user running apache needs write access to your repository. > Cheers / Erik > > On Tue, Apr 13, 2010 at 10:01 PM, Disc Magnet wrote: >> >> This is my configuration. >> >> >> DAV svn >> SVNParentPath /home/magnet/myrepository/ >> >> >> The checkout command runs fine: >> >> svn co http://localhost/myrepository/hachumachu >> >> However, the commit command results in this error: >> >> mag...@faku:~/hachumachu$ svn commit -m "Additional line" >> svn: Commit failed (details follow): >> svn: Can't open file >> '/home/magnet/myrepository/hachumachu/db/txn-current-lock': Permission >> denied >> >> This appears in my Apache error log: >> >> [Wed Apr 14 01:04:58 2010] [error] [client 127.0.1.1] Could not create >> activity >> /myrepository/hachumachu/!svn/act/a3cb143e-3098-499b-b7d1-5d5b7e982881. >> [500, #0] >> [Wed Apr 14 01:04:58 2010] [error] [client 127.0.1.1] could not begin >> a transaction [500, #13] >> [Wed Apr 14 01:04:58 2010] [error] [client 127.0.1.1] Can't open file >> '/home/magnet/myrepository/hachumachu/db/txn-current-lock': Permission >> denied [500, #13] >> >> In case you want to see the permissions on the folders. >> >> mag...@faku:~/myrepository$ ls -l >> total 12 >> drwxr-xr-x 4 magnet magnet 4096 2010-04-11 18:13 ondalabondala >> drwxr-xr-x 6 magnet magnet 4096 2010-04-11 18:12 hachumachu >> drwxr-xr-x 6 magnet magnet 4096 2010-04-11 19:36 haggupaggu >> >> Please help. > >
RE: Automatic upgrade of wc format annoying on shared drives
Jeremy Mordkoff wrote: >>> I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12), > various >>> ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4, >>> 10.5. When one of them upgrades, it causes me to scramble to build > and >>> deploy upgrades to the others. >>> >> But working copies should really be disposable. As long as you keep > your >> changes commited, if the format is a problem for a different client, > just delete >> it and let that client build what it wants. >> > > Our product also supports that variety of platforms. I request that > changes be tested on all platforms before the changes are committed. > That requires the engineer to either use a project branch or access a > view from multiple machines. Since some machines are shared, sometimes > views get inadvertently upgraded. > And you are not concerned that some uncommitted change in this working copy might be the thing that makes all your tests pass? I like to make 'svn checkout' or 'update' the only means to get the source to the testing platforms to ensure that the test is of a reproducible state. -- Les Mikesell lesmikes...@gmail.com Absolutely. We use svn:ignore and svn status to make it easy to make sure such things don't happen. And then we also have a QA group (this is for developer testing). I can't say they always adhere to it, but that can't say that their tools don't support it. jlm
RE: Automatic upgrade of wc format annoying on shared drives
> Jeremy Mordkoff wrote: > > I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12), various > > ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4, > > 10.5. When one of them upgrades, it causes me to scramble to build and > > deploy upgrades to the others. > > > > But working copies should really be disposable. As long as you keep your > changes commited, if the format is a problem for a different client, just delete > it and let that client build what it wants. > > -- >Les Mikesell > lesmikes...@gmail.com Our product also supports that variety of platforms. I request that changes be tested on all platforms before the changes are committed. That requires the engineer to either use a project branch or access a view from multiple machines. Since some machines are shared, sometimes views get inadvertently upgraded. Thanks Daniel. JLM
RE: Automatic upgrade of wc format annoying on shared drives
I second that. I support fedora 7, 8, 9, 10, 11 (and soon 12), various ubuntu releases, plus windows XP, Vista, and Win7, and Mac OS 10.4, 10.5. When one of them upgrades, it causes me to scramble to build and deploy upgrades to the others. JLM -Original Message- From: Simon [mailto:tzueskj...@snkmail.com] Sent: Mon 4/12/2010 9:17 PM To: users@subversion.apache.org Subject: Automatic upgrade of wc format annoying on shared drives We have work directories shared between many physical machines here (via sshfs, nfs, etc). We also use subversion as our configuration management system for source files. When a newer client ends up on on of the work machines, it automatically (and silently) upgrades the wc metadata format of any working copies it touches. This prevents future access of any of the other clients until the working copies are manually downgraded (such as via: http://subversion.apache.org/faq.html#working-copy-format-change ). This is quite annoying. I think correct behaviour here is that the client should at least prompt the user to ask if it should upgrade the wc metadata format before messing with the working copy. Failing that, is there some way of locking a working copy to a particular version of the wc metadata format. Regards, Simon
mergeinfo and reintegrate
> > We use a lot of project branches, that is, we branch from trunk, > > develop a feature and then merge it back to trunk. Quite often, we need > > to merge a change or two from trunk out to our branch along the way. > > What I have noticed is that when I go to merge the branch back to trunk, > > the changes that were merged from trunk to the branch are included when > > I do a 'svn mergeinfo --show-revs eligible '. Why is > > this? Shouldn't the system know that these were merged out and therefore > > do not need to be merged in? I do not ever use 'ignore-ancestry'. > > > > I end up doing a lot of 'svn merge --record-only's to block the reverse > > merges. > > If you have a feature branch you should be merging from trunk into the branch regularly. then > when you are done with the feature you would do a reintegrate merge back. I don't see an > argument on merginfo to specify that you want to do a re-integrate. > Svn help mergeinfo does not reference --reintegrate at all. Are you saying that a merge with the -reintegrate option may skip some items that mergeinfo lists as eligible? Also the help for reintegrate says that the only difference is that it treats the merge as a lump sum, not as a sequence of mini merges. Are you saying that if you have done a complete merge out, you can skip the individual merge ins and just do one big reintegrate? If so, Is doing a complete merge out first mandatory? (I would think so). Can this model handle files that were deleted and re-added? Actually, now that I have written and reread this, I think I answered my own question. Using reintegrate is orthogonal to using mergeinfo. You use mergeinfo to pick up changes that have been made in a release branch that need to be merged to trunk, and you use -reintegrate to merge a project branch back to its baseline. I feel like I must have missed that section in the book. Is this not documented? Thanks JLM
subscribing
I'm having trouble subscribing. if there's a trick please let me know. I sent mail to users-subscribe with just 'subscribe j...@zeevee.com' in the body no answer. We use a lot of project branches, that is, we branch from trunk, develop a feature and then merge it back to trunk. Quite often, we need to merge a change or two from trunk out to our branch along the way. What I have noticed is that when I go to merge the branch back to trunk, the changes that were merged from trunk to the branch are included when I do a 'svn mergeinfo --show-revs eligible '. Why is this? Shouldn't the system know that these were merged out and therefore do not need to be merged in? I do not ever use 'ignore-ancestry'. I end up doing a lot of 'svn merge --record-only's to block the reverse merges. Please reply directly as I do not seem to be able to subscribe. Thanks, JLM
