Re: Shared branch vs single branch
If by single/shared branch you mean everyone working out of the same place...then yes - you'll trip over each other from time to time. I've worked in both trunk is prestine (all work in branches) and trunk is dirty (all work in trunk) models; when you have multiple people the trunk is prestine works a lot better, but as others have noted people doing the merges have to ensure they are done right - and that includes testing. Trunk is dirty won't save you from bad merges, it'll just make more conflicts in your working copy as you do updates - something that drove a colleague of mine nuts so I started working in my own branch for that project. You also have to more frequently be doing svn update on your working copy to minimize impacts of what others are doing. $0.02 Ben From: C M cmanalys...@gmail.com To: Les Mikesell lesmikes...@gmail.com Cc: Bob Archer bob.arc...@amsi.com; Subversion users@subversion.apache.org Sent: Monday, September 23, 2013 4:04 PM Subject: Re: Shared branch vs single branch Unfortunately, we are lacking on processes and there's a definite lack of product management. But coming back to my original question: Are there any potential gotchas with using a single/shared branch? For now, that's the only change the team (and leadership) is looking to as the solution. Our developers code on a Unix like platform and have little SVN experience to boot. The idea of turning over merging to them seems to be a recipe for disaster. I would prefer to let the CM team handle the merges and figure out what I did incorrectly to mess up the previous merges. On Mon, Sep 23, 2013 at 2:42 PM, Les Mikesell lesmikes...@gmail.com wrote: On Mon, Sep 23, 2013 at 2:35 PM, Bob Archer bob.arc...@amsi.com wrote: On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer bob.arc...@amsi.com wrote: It really depends. I think all work for a specific release should be done in a single branch/folder. Many people follow the stable trunk model. In this model you generally do all work on trunk and then branch for a release. This is the same model svn itself is developed under. In this model you would also use what are called feature branches. This is generally for a feature/use case that will take more than a day to complete or will be worked on by more than one developer. Once again, it's up to the people not the tool to ensure your release management is done properly. Well, sort-of. It is always a good idea to (a) include tests for new code and (b) have a workflow that ensures that the tests are run and that someone checks the results. Expecting one person to never make a mistake just doesn't always work out. Isn't is up to the people to put those processes in place? To create the correct workflow? To write the automation? I don't think I ever said it should be ONE person's responsibility to manually do this work. Where did I say that? You didn't explicitly say it was one person's fault, but what you said could easily be interpreted that way by anyone who had to ask the question in the first place Yes, people have to set things up, but there are tools that can help. -- Les Mikesell lesmikes...@gmail.com
Re: Tags - Symbolic names instead of Directory copy?
From: Thorsten Schöning tschoen...@am-soft.de To: users@subversion.apache.org Sent: Thursday, May 23, 2013 2:49 AM Subject: Re: Tags - Symbolic names instead of Directory copy? G uten Tag Varnau, Steve (Seaquest RD), am Donnerstag, 23. Mai 2013 um 01:57 schrieben Sie: In my opinion, the same semantics work less well for tags. My biased mind-set is that a “tag” is a name identifying a specific version of code (a cross product of “branch” and “revision”). I don't see the point, as you already know that it's not handled that way in Subversion and you need to make the same conclusions for tags and branches. In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. Simply use them that way, like you said for branches. But a “tag” that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. Because from my understanding you compare two things which have nothing to do with each other: One is how branches and tags are created, both the same way, but the other is what happens afterwards to each. As branches and tags are technically the same, only differing by convention, they of course work equally and therefore need to share the same semantics. Checkout is fine, I get the right version of the code. Update gives me the message that my workspace is up to date. Only if it is update, meaning no one ever committed anything to your tag. If commits were made, your working copy would not be up to date anymore, of course. It sounds to me like you compare branches with per convention immutable tags to come to the conclusion that both have different semantics. But that's not the case, just a result of your immutable tags convention. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. Because with checking out a tag and keeping it immutable you want that tag and not trunk. Or what's the reason for checking out that special tag at all? Especially if you know it's immutable, if it wouldn't be immutable you of course would get new commits. I think he's thinking of CVS style tags, which are mutable in that you can modify which version of different files have the tag. So everyone works on HEAD and a STABLE tag progresses across it as developers decide different ports are stable. However, as you've mentioned and was more at length discusses elsewhere that's simply not have SVN works. A similar kind of workflow for SVN would be: Main work: /trunk Trunk Stable tag or branch: /tags/trunk-stable or /branches/trunk-stable Do work in /trunk, as things are declared stable merge to /branches/trunk-stable. While I have in the past been able to sympathize with people looking for CVS-style tags (and still do to some extent), I think Subversion style Tags are far more superior primarily from the fact that you can track any changes that are happening to the tag, which you could not do with CVS. Ben
Re: Tags - Symbolic names instead of Directory copy?
From: Varnau, Steve (Seaquest RD) steve.var...@hp.com To: BRM bm_witn...@yahoo.com; users@subversion.apache.org users@subversion.apache.org Cc: Thorsten Schöning tschoen...@am-soft.de Sent: Thursday, May 23, 2013 1:40 PM Subject: RE: Tags - Symbolic names instead of Directory copy? From: BRM [mailto:bm_witn...@yahoo.com] From: Thorsten Schöning tschoen...@am-soft.de To: users@subversion.apache.org Sent: Thursday, May 23, 2013 2:49 AM Subject: Re: Tags - Symbolic names instead of Directory copy? G uten Tag Varnau, Steve (Seaquest RD), am Donnerstag, 23. Mai 2013 um 01:57 schrieben Sie: In my opinion, the same semantics work less well for tags. My biased mind-set is that a “tag” is a name identifying a specific version of code (a cross product of “branch” and “revision”). I don't see the point, as you already know that it's not handled that way in Subversion and you need to make the same conclusions for tags and branches. In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. Simply use them that way, like you said for branches. But a “tag” that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. Because from my understanding you compare two things which have nothing to do with each other: One is how branches and tags are created, both the same way, but the other is what happens afterwards to each. As branches and tags are technically the same, only differing by convention, they of course work equally and therefore need to share the same semantics. Checkout is fine, I get the right version of the code. Update gives me the message that my workspace is up to date. Only if it is update, meaning no one ever committed anything to your tag. If commits were made, your working copy would not be up to date anymore, of course. It sounds to me like you compare branches with per convention immutable tags to come to the conclusion that both have different semantics. But that's not the case, just a result of your immutable tags convention. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. Because with checking out a tag and keeping it immutable you want that tag and not trunk. Or what's the reason for checking out that special tag at all? Especially if you know it's immutable, if it wouldn't be immutable you of course would get new commits. I think he's thinking of CVS style tags, which are mutable in that you can modify which version of different files have the tag. So everyone works on HEAD and a STABLE tag progresses across it as developers decide different ports are stable. My example was a poor choice, as I prefer non-mutable tags, but there are certainly use-cases for mutable and non-mutable. There are certainly examples from other versioning tools. Baselines concept in ClearCase, that can be defined then locked. But those get too complex very fast. I really prefer the kind of simplicity in Svn. However, as you've mentioned and was more at length discusses elsewhere that's simply not have SVN works. Agreed. I understand how Svn works, and it's fine how it works. But I'm arguing that I'd like to see an additional type of object that would be useful... One way to do that would be to have another directory that you have the hook scripts configured to make read-only. So: /trunk /branches /tags /tags-readOnly Again, you're going to a hook-script to do it as that is how SVN enforces it best. Yes, there is the permissions structure but there's no easy way to do a globular matching like the following: [/*readOnly*] @users = r That is certainly one feature that would be very handy if ever implemented. A similar kind of workflow for SVN would be: Main work: /trunk Trunk Stable tag or branch: /tags/trunk-stable or /branches/trunk- stable Do work in /trunk, as things are declared stable merge to /branches/trunk-stable. While I have in the past been able to sympathize with people looking for CVS-style tags (and still do to some extent), I think Subversion style Tags are far more superior primarily from the fact that you can track any changes that are happening to the tag, which you could not do with CVS. Ben Subversion implements a versioned filesystem model (add, cp, mv, rm). If it also had a notion of a symlink (ln) that allows reference to path@revision, then it gives the same tracking of changes to a tag that you mention. But then other operations like checkout operate on what it points to. Then you really get baseline-label-tag type semantics instead of branch semantics. And to get those semantics, you don't really need hook scripts or special permissions to treat them
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
From: Andrew Reedick andrew.reed...@cbeyond.net -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Tuesday, May 21, 2013 3:53 PM To: Andrew Reedick Cc: Branko Čibej; users@subversion.apache.org Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects? The client should only see and work with --project project1 --branch 1.0, e.g. svn co --project project1 --branch 1.0 to checkout a branch. That's sort of like saying filesystems shouldn't have subdirectories so users don't get confused... Some people might even believe that. And there's a reason why 'pwd' returns '/home/userid' instead of '/dev/sda1/home/userid' or 'server-vol0.foo.net:/vol0/userid'. Or why 'cd ~' takes you to your home dir. Well, cd ~ is imposed by the shell environment, not by kernel. And /dev/sda1 being / is imposed by the kernel, not the shell; but the kernel only knew to map it that way because the user told it to. The issue is the same as with SVN. SVN does not know anything about what users mean by the URL paths; it only knows about the paths it implements. A higher level piece of software could do additional mappings and hide all those details - just like the kernel does for user level programs when it is told to map /dev/sda1 to /; but that higher level piece of software has to be configured to do that, just like the kernel does. It's about presentation. Keep the superfluous dir components internal and hidden from the average user. We've already seen a move towards information hiding with the'^' syntax that hides the server component. This would be the logical progression. It's about organization. And letting you arrange your own conventions to match your processes. We'll have to agree to disagree. We're back at the low level managing dirs versus high-level managing baselines arguments/thinking/paradigms. As others have stated, SVN provides the engine to do the work - just like the kernel provides the engine to read the disk drive. However, unlike the kernel it has no higher level functions that do mappings it can understand. It's just the core, and while it is pretty smart about what it does it is also pretty dumb about what it doesn't do - just like a kernel file system driver is very smart about reading the file system but very stupid about what the directories or files the user puts in the file system mean. Or more to the point, you can think of it like this: Apache2 = Kernel - maps https://mysvnserver/svnrepopath to / SVN = File System Driver for the kernel Of course, svnserve mixes the two, but that's really the gist of it as it relates to your example. Ben
Re: SVN Externals 1.6 to 1.7 migration issue
While I have not had the issue you are having, assuming the externals are in the same repository I would highly recommend changing from using the syntax you have to using the carrot (^) operator as it will save you many headaches if your original svn location changes. I.e. use: ^/FOLDER_A FOLDER_C ^/FOLDER_B FOLDER_D Also, I think the specific issue you are having (looking more closely at the error message below) is that AFAIK, SVN does not let you import specific files via externals - you have to do name spaces (aka folders) instead. I would suggest doing one of two things in a batch file that gets run after checkout (manually by the user, though TSVN may be able to give you some automatic client-side scripting): 1. Use mklink to create an NTFS file link after the checkout for the file you are trying to relocate. 2. Copy the file from the one directory to the other Or 3. Copy the file as part of the SVN source tree to the other folder; but you'll also have to continuously merge the changes back and forth. #1 is your best option if you want to not change anything at all, but requires that you are running a newer version of Windows than Windows XP. I think Microsoft first started providing the mklink utility with Vista; but it could be WIn7, and might also depend on which edition of each of those you have as well. (e.g. it might not be in the Home Premium version, but might be in Pro and Ultimate). #2 is an okay backup if you can't do #1, but you'll need to treat the file as read-only as it will certainly be very much manual effort to maintain. #3 is automatic, but you'd have to ensure the file matches what is at its origin - a bit of a manual effort, but easy to do. $0.02 Ben From: Hutchinson, Steve (UK) steven.hutchin...@mbda-systems.com To: users@subversion.apache.org users@subversion.apache.org Sent: Wednesday, May 1, 2013 7:01 AM Subject: SVN Externals 1.6 to 1.7 migration issue Hi, We're been using 1.6 svn externals to manage a FW task. In the repository we have a folder structure (which is pretty much defined by the tools we are using) as below :- FOLDER A - file_a1.txt, file_a2.txt, file_a3.txt FOLDER B - file_b1.txt, file_b2.txt, file_b3.txt Then using externals we link to those folder to create a WC PROJECT structure that looks like :- PROJECT - FOLDER C - file_a1.txt, file_a2.txt, file_a3.txt AND file_b1.txt PROJECT - FOLDER D - file_b1.txt, file_b2.txt, file_b3.txt The externals on PROJECT FOLDER we used looked like (not actually using file protocol, just created for example purposes) :- file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt Worked ok with 1.6. We get the below error in 1.7 when updating of :- External failed: D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt Error: Cannot insert a file external defined on 'D:\FPGA\SVN_ISSUE\PROJECT' into the Error: working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'. We have tried a few things (will not share all at this point due to info overload), but wondered if there were any others that achieve something like this with 1.7 or could offer some advise ? Thanks for any help. Regards Steve H This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England.
Re: Changelist support for svn patch?
So what if you have changes to the local working copy? Or are you ensuring you have no other changes first? As Branko Čibej noted, the only clean way to do it is to use a new (or a dedicated) working copy. Sadly, there is nothing like TSVN for Linux. Ben From: Nick nos...@codesniffer.com To: BRM bm_witn...@yahoo.com Cc: users users@subversion.apache.org; d...@subversion.apache.org d...@subversion.apache.org Sent: Wednesday, April 17, 2013 4:12 PM Subject: Re: Changelist support for svn patch? On Wed, 2013-04-17 at 11:42 -0700, BRM wrote: I'd suggest a slight modification to your process if you can - that is: 1. Checkout a new working copy 2. Apply the patch to the new working copy 3. Review 4. Delete the new working copy Now I realize in some cases that may not be an option - too large a down, etc. Right, checking out a new WC for each code review is not feasible for me, and sort of seems like overkill. I figure the worst case scenario is to generate a script which parses the patch and downloads a local copy of each file referenced in the patch (at the specified rev) into a temporary tree (sort of a sparse checkout), apply the patch to the tree, and then can launch a diff tool against it. If the patch provider is using SVN, which I assume they are since you're talking about apply a patch with SVN, then if it is all committed you could also use TSVN's Repository Viewer to look at the patch by comparing two branches, and then using TSVN's Diff functionality to look at each modification, just like you are in your working copy - only you don't need a working copy to do it. I'm using Linux, otherwise I'd just use TortoiseSVN which seems to be able to do what I describe above. Any how...something to think about for you. Ben P.S. Aren't Changelists client-side only? Yes, they are client-side only. __ From: Nick nos...@codesniffer.com To: Philip Martin philip.mar...@wandisco.com Cc: users users@subversion.apache.org; d...@subversion.apache.org Sent: Wednesday, April 17, 2013 10:23 AM Subject: Re: Changelist support for svn patch? On Wed, 2013-04-17 at 11:43 +0100, Philip Martin wrote: The 'patch' subcommand does not seem to support applying a changelist description to the files that are part of the patch. Any plans to support this? (Should I be asking this on the dev list?) That sounds like a useful feauture. Here's the workflow which provoked my asking. I wonder if there's an alternative (and maybe more streamlined) method of accomplishing the same. I received a patch containing a feature addition for a project I'm working on. My primary interest is only to view the changes (ie. code review)--not to submit them. AFAICT, the way to do this using subversion directly (ie. not a wrapper app like TortoiseSVN) is to apply the patch to my working copy and then view the diff. (I'm ignoring the option of viewing the raw patch file directly in an editor.) Once I'm done reviewing, I want to remove the change. Without the ability to apply the patch into a specific changelist, I have to surgically revert the changes if I have other changes of my own in the WC. If the patch were applied to a changelist, I can revert it all in one shot. Am I missing something for this workflow? Is there a simpler way? How do others handle this scenario? Nick
Re: Changelist support for svn patch?
I'd suggest a slight modification to your process if you can - that is: 1. Checkout a new working copy 2. Apply the patch to the new working copy 3. Review 4. Delete the new working copy Now I realize in some cases that may not be an option - too large a down, etc. If the patch provider is using SVN, which I assume they are since you're talking about apply a patch with SVN, then if it is all committed you could also use TSVN's Repository Viewer to look at the patch by comparing two branches, and then using TSVN's Diff functionality to look at each modification, just like you are in your working copy - only you don't need a working copy to do it. Any how...something to think about for you. Ben P.S. Aren't Changelists client-side only? From: Nick nos...@codesniffer.com To: Philip Martin philip.mar...@wandisco.com Cc: users users@subversion.apache.org; d...@subversion.apache.org Sent: Wednesday, April 17, 2013 10:23 AM Subject: Re: Changelist support for svn patch? On Wed, 2013-04-17 at 11:43 +0100, Philip Martin wrote: The 'patch' subcommand does not seem to support applying a changelist description to the files that are part of the patch. Any plans to support this? (Should I be asking this on the dev list?) That sounds like a useful feauture. Here's the workflow which provoked my asking. I wonder if there's an alternative (and maybe more streamlined) method of accomplishing the same. I received a patch containing a feature addition for a project I'm working on. My primary interest is only to view the changes (ie. code review)--not to submit them. AFAICT, the way to do this using subversion directly (ie. not a wrapper app like TortoiseSVN) is to apply the patch to my working copy and then view the diff. (I'm ignoring the option of viewing the raw patch file directly in an editor.) Once I'm done reviewing, I want to remove the change. Without the ability to apply the patch into a specific changelist, I have to surgically revert the changes if I have other changes of my own in the WC. If the patch were applied to a changelist, I can revert it all in one shot. Am I missing something for this workflow? Is there a simpler way? How do others handle this scenario? Nick
SVN wc/repo issue...
I have a repository with many projects in it, and have been working on the layout of one project in particular - adding directories and moving source into it. I am now trying to move a directory in that projects part of the tree to another part of the tree, simply: $ svn mv ../../include . However, 'svn mv' keeps returning: Unable to lock '.' I've tried it from several working copies - including one fresh checkout, all with the same result. We don't typically use locks in the repository, and I'm the only person working on this part of the tree - and no locks in it. 'svn status' does not return any files as having been locked, and 'svn cleanup' doesn't seem to resolve the issue either. Is there any way to tell what might be locked on the server side? Any other ideas of what to check? I didn't see any issues in the Apache2 logs, at least anything obvious. We're using Apache2/2.2.22 + Subversion 1.6.17 as the server (Ubuntu Releases); and I'm using 1.6.19 on the client (compiled under Kubuntu 8.04). Ben
Re: SVN wc/repo issue...
Thanks. I didn't think any server-side locks were involved, but didn't know if a commit earlier on may have done something on the server-side. I did get around it by using the svn mv command to do a server-to-server move - kind of like doing it in TSVN's Repository Browser; and that worked just fine. I'll have to look to see if upgrading the client to 1.7 is feasible - though I don't do this specific task very often; it's just a matter of whether there's enough dependencies in 8.04 to support 1.7 series; I already had to build 1.6 for it (since Debian/Ubuntu only supports 1.5 for 8.04). Thanks! Ben From: Philip Martin philip.mar...@wandisco.com To: BRM bm_witn...@yahoo.com Cc: SubVersion Users users@subversion.apache.org Sent: Wednesday, April 3, 2013 4:11 PM Subject: Re: SVN wc/repo issue... BRM bm_witn...@yahoo.com writes: $ svn mv ../../include . However, 'svn mv' keeps returning: Unable to lock '.' Is there any way to tell what might be locked on the server side? The error does not involve a server-side lock. We're using Apache2/2.2.22 + Subversion 1.6.17 as the server (Ubuntu Releases); and I'm using 1.6.19 on the client (compiled under Kubuntu 8.04). It's a bug in the 1.6 client that is fixed in 1.7. You can work around it in 1.6 by doing $ cd ../.. $ svn mv include foo/bar -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: Tagging svn:externals
From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Wednesday, February 27, 2013 5:49 PM Subject: Re: Tagging svn:externals On Wed, Feb 27, 2013 at 4:44 PM, BRM bm_witn...@yahoo.com wrote: Won't work - it has to be committed somewhere or it won't be built. Perhaps then you need a different tool. For example, git-svn[1] is might be what you want. When something is ready for QA it is pushed to a git repository for Jenkins to pick up. How you change the externals in the process I'm not sure; but it would at least give you a trackable repository that would mimick a modified working copy. Otherwise I think you're out of luck if you don't want to (i) commit to trunk, or (ii) create a branch, but still want to track it in the repository somehow. No, I think the choices are to tag from the working copy or commit a change after making the tag. But neither seem like the tool is designed to do what I'd expect to be a common operation cleanly. What do you mean? Branching from a working copy is extremely easy: $ svn copy . ^/path/to/tag/or/branch It's a first-class operation in subversion. Likewise, you can: $ svn copy . ^/path/to/tag/or/branch $ svn switch ^/path/to/tag/or/branch ...make modifications here.. $ svn commit Ben
Re: Tagging svn:externals
From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Thursday, February 28, 2013 5:29 PM Subject: Re: Tagging svn:externals On Thu, Feb 28, 2013 at 3:34 PM, BRM bm_witn...@yahoo.com wrote: No, I think the choices are to tag from the working copy or commit a change after making the tag. But neither seem like the tool is designed to do what I'd expect to be a common operation cleanly. What do you mean? Branching from a working copy is extremely easy: $ svn copy . ^/path/to/tag/or/branch It's a first-class operation in subversion. Yes, that does work and seems like a reasonable thing if no change other than the externals is done. But if you aren't careful, you can easily add items that don't exist anywhere else. And you have to revert your change before continuing commits to trunk. Likewise, you can: $ svn copy . ^/path/to/tag/or/branch $ svn switch ^/path/to/tag/or/branch ...make modifications here.. $ svn commit Likewise, something that works, but if it is a tag you are violating the convention of not committing changes to tags. Leaving the question of which of these would be considered a 'best practice'. You could always use a slightly modified structure for your projects: trunk tags branches qa Your tagging for QA could be done to the qa tree, and then you are no longer breaking the rule of not modifying tags. You also enforce that actual tags (under the tags tree) must from from the qa tree; this can be hard-enforced with a pre-commit hook, or soft enforced in project policy alone. Ben
Re: Tagging svn:externals
From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Tuesday, February 26, 2013 6:12 PM Subject: Re: Tagging svn:externals On Tue, Feb 26, 2013 at 4:29 PM, BRM bm_witn...@yahoo.com wrote: How can a script possibly know the correct tag for an external target which is currently pointing at the trunk in a repository that permits concurrent operations? In my example, it would simply update, then pull the revision number to generate the peg revision information in the svn:externals data, essentially: ^/somePath@r1829 -r 1829 The 1829 portion is easily scriptable to find. But that's not what I want. I want the externals in tags to point to previously tagged component versions. Without forcing that to be committed to the trunk or encouraging copying to tags from a workspace that doesn't match any trunk commit. From that description, it'll have to be a manual process that you run from within your working copy. Just update the svn:externals appropriately and then do an svn update. You can test whatever you like without committing. As you can probably guess, I'm a big fan of trunk is prestine; mostly because I'm a big fan of doing things in a very structured, deterministic way. I'm a fan of not cluttering the repository with unnecessary branches, and in making it simple for everyone involved to pick up each others' changes sooner rather than later. And in getting determinism through consistent tagging, and only using release tags where determinism matters. So if you don't need a branch, delete it. Personally I do an svn del on any branch that I no longer need - whether abandoned or reintegrated. This keeps the branch list short, and (more importantly) relevant. The nice thing with Subversion is that you can still get to all those old branches. You seem to be wanting that determinism. It'd be interesting to see what a big fan of trunk is dirty would say for how to do the same thing; but somehow I suspect you can't do it while maintaining the determinism. The question is just about what would be considered best practice in where/how that change between an unpinned external and one pointing to a separately released tagged version should happen. I don't think whether the ongoing work is a branch or trunk matters. As long there is continuing (possibly concurrent) development in the location before you make the tag, you have to decide whether to (a) make another branch just to hold this change, (b) commit the change back to the development location, then undo it after the tag copy, (c) copy to the tag from a modified working copy, or (d) change it in the tag, violating the 'tags never change' convention? I personally don't like the idea of tagging from a modified working copy because of the possibility that other changes with no history can accidentally be brought along. Let me propose this: For QA, let them do a simple modified working copy to get the svn:externals where you want them; but then they are not allowed to commit or make other changes. You'll have to decide how you want bug fixes to be interacted with; but that will provide what you've been describing. For developers, they can do whatever you like. Again, as I've noted it comes down to what policies you want your team to follow. Ben
Re: Tagging svn:externals
From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Wednesday, February 27, 2013 5:30 PM Subject: Re: Tagging svn:externals On Wed, Feb 27, 2013 at 4:14 PM, BRM bm_witn...@yahoo.com wrote: But that's not what I want. I want the externals in tags to point to previously tagged component versions. Without forcing that to be committed to the trunk or encouraging copying to tags from a workspace that doesn't match any trunk commit. From that description, it'll have to be a manual process that you run from within your working copy. Just update the svn:externals appropriately and then do an svn update. You can test whatever you like without committing. Everything is built by jenkins and has to come from the repository. Things in uncommitted workspaces aren't necessarily repeatable. ,,, Let me propose this: For QA, let them do a simple modified working copy to get the svn:externals where you want them; but then they are not allowed to commit or make other changes. Won't work - it has to be committed somewhere or it won't be built. Perhaps then you need a different tool. For example, git-svn[1] is might be what you want. When something is ready for QA it is pushed to a git repository for Jenkins to pick up. How you change the externals in the process I'm not sure; but it would at least give you a trackable repository that would mimick a modified working copy. Otherwise I think you're out of luck if you don't want to (i) commit to trunk, or (ii) create a branch, but still want to track it in the repository somehow. Ben [1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
Re: Tagging svn:externals
From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Friday, February 22, 2013 10:57 AM Subject: Re: Tagging svn:externals On Fri, Feb 22, 2013 at 9:02 AM, BRM bm_witn...@yahoo.com wrote: Not only does it solve the above, but it also enforces a discipline in how projects are updated to use newer versions of the tags; it also requires developers to be aware of which externals affect which projects - which, IMHO, is a good thing. Sure, it would be great if every component had well-tested, frozen APIs at release quality before any upper level project touched them. But on the other hand, APIs tend to miss the mark if they aren't adjusted for the needs of real-world use. So there's a problem either way All true. But that's what your release process is for. Part of my release process for the projects that use svn:externals is to first tag and release any externals that are not released already. Agreed, but the scenario is making a QA tag from trunk work. Most of these are dead ends if QA rejects them - that is, with rare exceptions anything that needs to be fixed would be fixed on the trunk and a new QA tag made. My thinking is that there really should be an intermediate QA branch where the externals are pinned but it seems like a big waste when there will never be any other change on that branch. Plus, we are increasingly automating this with a jenkins plugin that allows tagging after a build. It's fully a matter of how you structure release process for anyone. If you keep trunk prestine, then I don't think that would be an issue - your process just has to say that trunk can only have released svn:externals and always be ready for QA. And QA would have to have a similar process specified for any updates they do. Ultimately nothing I/we say can do anything but help you define the process and how it needs to work for you and your team(s). And if I don't need to modify an external during development, then it never moves from the release the project used. Sure, many/most stay tied to tagged component releases even during trunk work on the upper level projects, but it is still a common scenario to need to make changes in both simultaneously. I don't think that would be an issue. Again, it's how you define the process for your developers/QA Testers/QA Fixers. Now, in a sense you're looking to do that automatically as you make a release of the project you're working on. But it really all comes down to the release process, the tools you use for release, and their capabilities. I don't think you can do it automatically unless you pin to peg revisions in the same repository. How would anything automatic find the right component tag or deal with concurrent changes in a separate repo? By automation I mean having scripts setup that can update the pegs revisions or tags automatically. It can be relatively easy to do (depending on the scripting language) but will be very specific to your repository use. The script would just need to be able to parse svn pget svn:externals and svn info on the various externals. I'm not saying its the full solution - or even the right one; just that that is how you are seeming to want to go. Personally I think the right solution is defining your processes for everyone. Keep it easy to do, but make sure everyone understands what they are suppose to do. Ben
Re: Tagging svn:externals
From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Tuesday, February 26, 2013 11:56 AM Subject: Re: Tagging svn:externals On Tue, Feb 26, 2013 at 8:48 AM, BRM bm_witn...@yahoo.com wrote: Agreed, but the scenario is making a QA tag from trunk work. Most of these are dead ends if QA rejects them - that is, with rare exceptions anything that needs to be fixed would be fixed on the trunk and a new QA tag made. My thinking is that there really should be an intermediate QA branch where the externals are pinned but it seems like a big waste when there will never be any other change on that branch. Plus, we are increasingly automating this with a jenkins plugin that allows tagging after a build. It's fully a matter of how you structure release process for anyone. If you keep trunk prestine, then I don't think that would be an issue - your process just has to say that trunk can only have released svn:externals and always be ready for QA. And QA would have to have a similar process specified for any updates they do. We do development on trunk. It just seems like the logical place... That's one of two recognized methods - trunk is prestine or trunk is dirty. For trunk is dirty there is no guarantee that any given revision is useable. For trunk is prestine development methodology says any given revision must be useable. Both are enforced by project preferences and policy. Ultimately nothing I/we say can do anything but help you define the process and how it needs to work for you and your team(s). On the other hand, it would be helpful if there were a best practices document on how best deal with the inherent conflict between the concepts of concurrent development on trunk, and the conventions of (a) externals always being pegged in tags and (b) no changes _after_ tagging. The only clean approach looks to me like making a branch whose only purpose is to be a place to make the change to the external references - but that also seem like a lot of extra effort and clutter in the repository for that operation. But, if that is what it takes, it would be easier to convince developers to do it that way if there were some official document describing it. From what I can tell - and others can verify this - Subversion tries to allow the developers to choose the development model that best fits their needs. As such, such a document would have to be generated for numerous development models. That said, I think what you're looking to do makes more sense in a trunk is prestine model than a trunk is dirty model. My own repositories use the trunk is prestine model. Sure, many/most stay tied to tagged component releases even during trunk work on the upper level projects, but it is still a common scenario to need to make changes in both simultaneously. I don't think that would be an issue. Again, it's how you define the process for your developers/QA Testers/QA Fixers. I'm just saying it would be nicer if every user didn't have to make up a different workflow process to accomplish the same thing... I think it's a matter of finding what works best for your team. Good tools, like Subversion, make it easy to customize your workflow for what you need to do. Some functions fit certain workflows better than others; but they are available. Now, in a sense you're looking to do that automatically as you make a release of the project you're working on. But it really all comes down to the release process, the tools you use for release, and their capabilities. I don't think you can do it automatically unless you pin to peg revisions in the same repository. How would anything automatic find the right component tag or deal with concurrent changes in a separate repo? By automation I mean having scripts setup that can update the pegs revisions or tags automatically. It can be relatively easy to do (depending on the scripting language) but will be very specific to your repository use. How can a script possibly know the correct tag for an external target which is currently pointing at the trunk in a repository that permits concurrent operations? In my example, it would simply update, then pull the revision number to generate the peg revision information in the svn:externals data, essentially: ^/somePath@r1829 -r 1829 The 1829 portion is easily scriptable to find. The script would just need to be able to parse svn pget svn:externals and svn info on the various externals. I'm not saying its the full solution - or even the right one; just that that is how you are seeming to want to go. Personally I think the right solution is defining your processes for everyone. Keep it easy to do, but make sure everyone understands what they are suppose to do. That is a lot easier if you can make that solution avoid extra work
Re: Tagging svn:externals
From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Thursday, February 21, 2013 11:09 AM Subject: Re: Tagging svn:externals On Thu, Feb 21, 2013 at 9:42 AM, BRM bm_witn...@yahoo.com wrote: On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer bob.arc...@amsi.com wrote: Some clients like TortoiseSVN have a feature that will pin the external to the revision you are copping when doing the tag. Otherwise, you have to do it manually before or after you create your tag. Neither choice 'feels' quite right to me unless you have an intermediate branch to make the change. That is, if you make it on the trunk before you copy to the tag you break the likely continuing work on the trunk that expects the externals to also follow trunk components. And if you change it in the tag you are breaking the convention that you don't change tags. And if you copy the working copy to a tag you might get other changes in the tag that weren't committed anywhere else. Is there a 'best practice' consensus for this step? While I do agree, I think the simple solution is to generally just use tagged externals to start with, and then switch them to trunk or a branch when you need to work on them from that project. That makes sense when you aren't concurrently working on a component and the project using it. But that is the problem case - and common. Not only does it solve the above, but it also enforces a discipline in how projects are updated to use newer versions of the tags; it also requires developers to be aware of which externals affect which projects - which, IMHO, is a good thing. Sure, it would be great if every component had well-tested, frozen APIs at release quality before any upper level project touched them. But on the other hand, APIs tend to miss the mark if they aren't adjusted for the needs of real-world use. So there's a problem either way All true. But that's what your release process is for. Part of my release process for the projects that use svn:externals is to first tag and release any externals that are not released already. And if I don't need to modify an external during development, then it never moves from the release the project used. Now, in a sense you're looking to do that automatically as you make a release of the project you're working on. But it really all comes down to the release process, the tools you use for release, and their capabilities. $0.02 Ben
Re: Authentication failure when SVNParentPath used
From: Raghu GS ragh...@gmail.com To: users@subversion.apache.org Sent: Tuesday, January 15, 2013 8:46 AM Subject: Authentication failure when SVNParentPath used I regret for bugging you once again. Apache authentication for the particular repository is failing when i use SVNParentPath, but working well when i use repo:/ instead of folder1:/repo1 in svnauthz file even without changing the apache configuration. I'll show my configuration below SVNAuthz file. [folder1:/repo1] john = rw joe = rw Apache configuration Location /parentfolder/folder1 Order allow,deny Allow from all DAV svn SVNParentPath /srv/svn/parentfolder/folder1 AuthType Basic AuthName svn repository AuthUserFile /srv/svn/config/userauthentication.conf Require valid-user AuthzSVNAccessFile /srv/svn/config/svnauthz.conf /Location Please assist me in resolving the issue. If you want to use the SVNParentPath directive to specify multiple repositories then you also need to set the Location directive to something different than you are thinking. Location .. directive should only point to the URL path of the base of the repository (single repository) or parent folder (SVNParentPath directive). Thus, you really want: Location /parentfolder ... SVNParentPath /svn/svn/parentfolder ... /Location All else being the same. HTH, Ben
SVN 1.7.5 curiosity...
I'm running SVN 1.7.5 Command-line client on Kubuntu 12.10 with latest updates. What puzzles me is that when I run svn status it no longer reports the status of any svn:externals. Is this expected behavior? Or is there a bug? Working Copy is proper version for 1.7 series so far as I know. Ben
Svn Copy question...
A colleague left and I am going through his laptop to checkin anything that was not committed already. As I don't know the state of things I'm copying stuff to their own branch - leaving the original source alone. However, I've run into an issue - one working copy is missing a folder; however, that folder does not appear to have been in source control at all. Another working copy of the same branch has the folder, but marked deleted - it was moved into a sub-tree I think. I don't know anything about this particular folder, but SVN is refusing to let me do an 'svn copy' without the branch. And I'd rather not do an svn update on the working copy as I want to maintain what is there without any changes for the moment. I'm doing: svn copy _dot_ svn.my.server.com/path/to/copy/to where _dot_ is a single period for the current directory (since it doesn't show up too well in e-mail/webmail/etc). Is there any way I can get around this? Ben P.S. In case it matters at all - Windows command-line client version of SVN installed is 1.6.9 (r901367) by CollabNet. SVN Server (on Apache2) version is 1.6.6.
Re: SVN Keywords...
- Original Message From: David Weintraub qazw...@gmail.com I'm not sure what you are planning on doing, but usually the RCS Keywords are not a good idea. They usually cause more problems than they solve. What usually works better (especially in C and C++) is to define macros at compile time that are embedded in your program as strings. For example, you could have an About Box that will display this information or if your run your program with a --version switch. I am already using some macros, etc. However, I find that using things that rely on the programmer to make a modification can be troublesome and it is far to easy to forget to change the version and build date information. Versus using the RCS keywords to record some of the same information. This will give you more flexible control -- for example, you can use a release number that corresponds to your tags. And, you don't have to worry about forcing programming changes just to munge the $Date$ keyword. I don't want to munge it. I just want to print it. I'm not even particular about the format.Which is why a URL last commit date RCS Keyword would work just fine. I've also seen some others in the past - such as autoincrementing a macro; however, that is even more broken as it requires it to be checked back in, so then two programmers could generate the same numbers separately. Ultimately there is no real good solution, only a series of solutions that are good enough and RCS keywords is one approach. It may not be for everyone, but it does have its purposes. However, if you must use RCS keywords, you can modify a property that will force a diff in the file without modifying the file itself. Again that would require the programmer to do something. Versus what I proposed, which would just work since as the name space gets copied from one URL (e.g. trunk) to another (e.g. tags) the property would automatically change. Additionally, svnversion doesn't work b/c it only works on the local working copy, which doesn't work when you've exported the code. (since it just reports that was exported). I've already gotten around the revision thing somewhat by requiring the programmer to include it in the release tag, and then having some custom code that can parse the HeadURL to get the information - but only b/c it knows how to decode it out of the tag name and it knows a little bit about our SVN repository structure. Ben
Re: Repository organization for complex project
Mauro, Yes, such things are possible. I have a similar project and my repository is setup as follows: /project /project/libraries /project/libraries/library /project/clients /project/clients/client /project/server /project/tools /project/tools/tool /project/other parts (project is optional - as I have many different suites of projects, I do this.) Each of the following has its own trunk, branches, and tags namespace: /project/libraries/library /project/clients/client /project/tools/tool /project/other parts Projects under /project/libraries are utilized by all the other projects, and linked in via svn:externals. So, for example, a testClient would be stored at /myProject/tools/testClient and have its own trunk, tags, and branches namespaces, and it may link in the myProjectNetworkProtocol library from /myProject/libraries/myProjectNetworkProtocol; during development of the protocol it might use a branch of the myProjectNetworkProtocol library; during a merge it may use the trunk; otherwise it would use a release from under the tags. I have also found it useful to use the Revision number (as reported by svn info) of the last modification on a trunk in the name of the tag. For example, if myProjectNetworkProtocol was last modified at revision 5734 then its release tag would be /myProject/libraries/myProjectNetworkProtocol/tags/Release_5734, even if I was making the release at revision 15000. This is mostly just easier to track in the repository; though I don't usually need maintain older versions - things usually get moved to the latest version instead so I don't have to worry about releasing a modification to an older release; though if I did it'd probably become Release_oldRev_newRev for tracking purposes. We are also contemplating a namespace for system releases - that is, a release of all the parts under /project, likely in /project/system/tags; something to just say these versions of all these parts go together. HTH, Ben From: Mauro Adolfo San Martin Ramas msmar...@userena.cl To: users@subversion.apache.org Sent: Wed, October 13, 2010 12:05:43 PM Subject: Repository organization for complex project Hi, So far I have been using svn in rather simple settings: at most some branches and merges limited to one dev tree. However, now I need to set up a repository for a project composed by several modules where different subprojects (comprised by subsets of modules) need to be compiled and tested independently. Usually each team is actively developing only one module but requires the latest (or stable) versions of some of the others to build and test. For instance, if p_i are projects and m_i are modules, I need to configure svn to support m_1 m_2 m_3 m_4 m_5 p_1 u u d p_2 d u u u p_3 u u d ... where d means active development of module j by project i, and u only use. Is such a setting possible with svn? Any advice will be greatly appreciated. Best Regards, Mauro San Martín
Re: Repository organization for complex project
- Original Message From: Les Mikesell lesmikes...@gmail.com We currently commit component binaries back into tags which are then used by other things with external references, and final binaries are managed separately by project, but that seems wrong on several levels. For the projects we do nightly builds on we use an FTP site that the build scripts upload the builds to. This is easy enough to script even on Windows - whether using DOS Batch or Windows Scripting Host. I'm sure Hudson and other build systems can handle that just fine. I'd like to find a generic scheme (and one that can be plugged into hudson if possible) to store build results with a versioning scheme that doesn't force you to keep them forever because most are obsolete after a few new builds but that has a close-coupling to the svn version or at least the tag name of the matching source. But this seems like it should be a common scenario and not something everyone re-invents differently. Well, right now I have a lot of projects that don't have a nightly build - mostly due to how Qt and Visual Studios interact - or rather, the problems in doing so. However, you can do a couple things to track this very well and automatically, partially supported via Subversion's Keyword Substitution. I use $HeadUrl$ in a number of projects to get the URL, which I then parse to get a information about the build; for example, if it's a tag then I grab the release information, or a branch then I build a special branch info to output. For things like the global revision number you'll need to use 'svnversion' to capture the output somehow. The following would probably work for you: 1. Capture the URL somewhere as part of checking it out using $HeadURL$ 2. As part of the build script run and capture the output of svnversion, you might want to do so with svn info too - though this only works if you are NOT doing an export. You can then store these with a copy of the source and resulting binaries to have full traceability. Alternatively, if you are using svn co in the build, just tarball or zip up the project's sandbox at the end of the build script and save it as a whole - this will keep ALL the information, URLs, versions, etc; for you - and is very build system friendly too. $0.02 Ben
Re: How to best manage authorization after tag/branch creation?
- Original Message From: Shaun Pinney shaun.pin...@bil.konicaminolta.us The usual issue is making sure people outside the project are prevented from reading the code. You might not want people in your project making changes on tags and branches, but there usually isn't a security issue if they see the code on the branches and tags. Our issue is handling multiple companies doing development on the same project. Various restrictions (e.g. licensing) prevent us from sharing all project files with everyone involved. It's a tricky use case. We also have additional considerations which require us to control project read access within a project even within the same company. The only way you can prevent people from reading your code is to setup httpd configuration. pre-commit hooks can't do this and there's no pre-checkout hook. Yeah, was afraid of that... I've always been an advocate of the Apache2+WebDAV setup for SVN. It's just easier. I know the apache access method (webdav) has path-based authentication; I don't know about the others. If you need to control access to the code you can do things such as: - only allow the developers that need access access to the whole project - setup a secondary tags namespace for special binary only information - have the build mechanism push the binaries to a special binary tag by the same name - use svn:externals to reference the binary releases instead of source releases. However, changing httpd configuration is tricky since it involves having root access on the httpd server and being able to at least bounce the server when the permissions get changed. Yes. Perhaps if there was a pre-checkout hook it'd be possible to create a homegrown admin tool. Or perhaps if Subversion had a feature to natively manage access control within a repository then no Apache changes would be needed in the first place. Either way, some automation would be useful here but it may not be possible to implement. By the way, there's also a way to configure Apache httpd to use LDAP instead of a regular text file. This means that users will have access to your Subversion repository based upon their Windows or Unix account and that users will automatically get logins and have their access removed when they get hired or move on. That's something we'll definitely consider. We have some other quirks with account management to sort out first :) When your development team gets bigger than a dozen people, you start having people come and go all the time. That makes it difficult to keep the httpd configuration up to date. It just becomes easier if this becomes more automated. Or at least someone else's problem when a new developer doesn't have access to Subversion. I completely agree, and will be using that argument to push for it (or at least the first part :) And that's why you use LDAP or another alternative authentication method. BTW, Subversion does support groups as part of the path-based authentication. I don't know how that interacts with LDAP if at all, but that might be something to investigate or perhaps add support for. $0.02 Ben
Re: Repository organization for complex project
- Original Message From: Les Mikesell lesmikes...@gmail.com To: BRM bm_witn...@yahoo.com On 10/13/2010 2:52 PM, BRM wrote: From: Les Mikeselllesmikes...@gmail.com We currently commit component binaries back into tags which are then used by other things with external references, and final binaries are managed separately by project, but that seems wrong on several levels. For the projects we do nightly builds on we use an FTP site that the build scripts upload the builds to. This is easy enough to script even on Windows - whether using DOS Batch or Windows Scripting Host. I'm sure Hudson and other build systems can handle that just fine. I'd like to find a generic scheme (and one that can be plugged into hudson if possible) to store build results with a versioning scheme that doesn't force you to keep them forever because most are obsolete after a few new builds but that has a close-coupling to the svn version or at least the tag name of the matching source. But this seems like it should be a common scenario and not something everyone re-invents differently. Well, right now I have a lot of projects that don't have a nightly build - mostly due to how Qt and Visual Studios interact - or rather, the problems in doing so. However, you can do a couple things to track this very well and automatically, partially supported via Subversion's Keyword Substitution. I use $HeadUrl$ in a number of projects to get the URL, which I then parse to get a information about the build; for example, if it's a tag then I grab the release information, or a branch then I build a special branch info to output. For things like the global revision number you'll need to use 'svnversion' to capture the output somehow. The following would probably work for you: 1. Capture the URL somewhere as part of checking it out using $HeadURL$ 2. As part of the build script run and capture the output of svnversion, you might want to do so with svn info too - though this only works if you are NOT doing an export. You can then store these with a copy of the source and resulting binaries to have full traceability. Alternatively, if you are using svn co in the build, just tarball or zip up the project's sandbox at the end of the build script and save it as a whole - this will keep ALL the information, URLs, versions, etc; for you - and is very build system friendly too. This covers the 'backtrack from binary' scenario as long as you keep those extra pieces in the zip with them. But I'm looking more for a filesystem and/or http URL name/path mapping to store the binaries so you can easily find the currently relevant versions in the first place. Among other things it should provide a straightforward way to replace our current svn externals to pull specific libraries into place for dependent builds, and also map to our branch/tag name structure for qa and production releases. Maven may be the right answer, but I was thinking in terms of something that could be viewed as a filesystem - maybe like alfresco where additional rules can be imposed. I actually have the $HeadUrl$ going into a source file in such a way as it is actually in the final build (since I actually parse it at run-time). If I ever edited the binary I would be able to read the URL. You can do the same with the others if you like, but getting them there can be more problematic and is build system specific on how to do so. The rest of it was per your statement: doesn't force you to keep them forever because most are obsolete after a few new builds but that has a close-coupling to the svn version or at least the tag name of the matching source. But this seems like it should be a common scenario and not something everyone re-invents differently. So you only keep the tarballs around as long as you like. You could alternatively toss them back into SVN, but then you'd be keeping them forever. Any how, just $0.02. Apply as desired. Ben
Re: Subversion 1.6.13 Released
Why not just install Apache2 on Windows and use the Apache2 DLLs for a WebDAV system? Far easier to manage. Ben From: Sjoerd Kivits sjo...@separator-spareparts.de To: users@subversion.apache.org Sent: Sat, October 2, 2010 8:36:46 AM Subject: RE: Subversion 1.6.13 Released RE: Subversion 1.6.13 Released Hi, Is it possible to download windows binaries for subversion server somewhere? I could only find packages including apache and so on... Brg, Sjoerd -Oorspronkelijk bericht- Van: hy...@hyrumwright.org namens Hyrum Wright Verzonden: vr 1-10-2010 19:12 Aan: announce Onderwerp: Subversion 1.6.13 Released I'm happy to announce Subversion 1.6.13, available from: http://subversion.tigris.org/downloads/subversion-1.6.13.tar.bz2 http://subversion.tigris.org/downloads/subversion-1.6.13.tar.gz http://subversion.tigris.org/downloads/subversion-1.6.13.zip http://subversion.tigris.org/downloads/subversion-deps-1.6.13.tar.bz2 http://subversion.tigris.org/downloads/subversion-deps-1.6.13.tar.gz http://subversion.tigris.org/downloads/subversion-deps-1.6.13.zip This is a bugfix release, part of the 1.6.x release series. Of note, this release includes a fix which addresses CVE-2010-3315, a security issue when using 'SVNPathAuthz short_circuit'. More information can be found here: http://subversion.apache.org/security/CVE-2010-3315-advisory.txt The MD5 checksums are: 7ae1c827689f21cf975804005be30aeb subversion-1.6.13.tar.bz2 8451f5d771edc0a0302bd9a52d54e150 subversion-1.6.13.tar.gz dd4009b239a5354b434e5f66cddde145 subversion-1.6.13.zip 2a7d662bac872c61a5e11c89263d7f07 subversion-deps-1.6.13.tar.bz2 688bdb107731f9db2f3b6297b663a68d subversion-deps-1.6.13.tar.gz bb960d37f835e5e556e23e4eb85a9b08 subversion-deps-1.6.13.zip The SHA1 checksums are: 185efd129c3c4b04f1544d62bb9a3fcd0f58ba29 subversion-1.6.13.tar.bz2 06d3afc49182c80ea712c13409c008d27a4e889b subversion-1.6.13.tar.gz 6530528fae0335cd8495ebf1f2072e2dd9df2e31 subversion-1.6.13.zip e51bffda416a3a9abe068aab6f90d174dedef352 subversion-deps-1.6.13.tar.bz2 1faa5ba0c87210f534ed445d061e4955396524d4 subversion-deps-1.6.13.tar.gz 945ef9f68998aedf320af50d220e47a470684a06 subversion-deps-1.6.13.zip PGP Signatures are available at: http://subversion.tigris.org/downloads/subversion-1.6.13.tar.bz2.asc http://subversion.tigris.org/downloads/subversion-1.6.13.tar.gz.asc http://subversion.tigris.org/downloads/subversion-1.6.13.zip.asc http://subversion.tigris.org/downloads/subversion-deps-1.6.13.tar.bz2.asc http://subversion.tigris.org/downloads/subversion-deps-1.6.13.tar.gz.asc http://subversion.tigris.org/downloads/subversion-deps-1.6.13.zip.asc For this release, the following people have provided PGP signatures: Senthil Kumaran S [1024D/6CCD4038] with fingerprint: 8035 16A5 1D6E 50E2 1ECD DE56 F68D 46FB 6CCD 4038 Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Paul T. Burba [1024D/53FCDC55] with fingerprint: E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 Julian Foad [1024D/353E25BC] with fingerprint: 6604 5A4B 43BC F994 5728 351F 33E4 353E 25BC Bert Huijben [1024D/9821F7B2] with fingerprint: 2017 F51A 2572 0E78 8827 5329 FCFD 6305 9821 F7B2 Hyrum K. Wright [1024D/4E24517C] with fingerprint: 3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C Stefan Sperling [1024D/F59D25F0] with fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0 Mark Phippard [1024D/035A96A9] with fingerprint: D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9 Release notes for the 1.6.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.6.html You can find the list of changes between 1.6.13 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.6.13/CHANGES Questions, comments, and bug reports to us...@subversion.apache.org. Thanks, - The Subversion Team
Re: Hook Script Examples
- Original Message From: Ryan Schmidt subversion-20...@ryandesign.com On Sep 10, 2010, at 10:50, BRM wrote: My old subversion server had a hookscript to deny commits unless there was a log message. I'd like to setup the same functionality on the new subversion server too. I already got my hook-scripts in place, but... Note the hook script to deny commits that have no log message is what you get in the default pre-commit.tmpl file that Subversion creates in every new repository. Yes, that is very nice. I did have to add a message though - so that users would get some kind of feed back as to why it was denied. Where as the pre-revprop-change.templ provides some default log message info. In the process, I came across the following README files: http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/README http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/README ; both of which references the old tigris.org site: http://subversion.tigris.org/tools_contrib.htmlHoweve, the page is no longer available, and I can't find it on the new apache.org site either. Is this page just simply no longer going to be available? Or is there somewhere else for this stuff now? The files are here: http://svn.apache.org/repos/asf/subversion/trunk/contrib/ The tools_contrib.html page was removed earlier this year: http://svn.apache.org/viewvc?view=revisionrevision=900549 That's fine; however, my point for bringing this up is that there is stuff still referencing that page. Those references should get updated. That's all. Ben
Re-integration Q...
I am running into the error: svn: Cannot reintegrate from 'url://feature-branch' yet: Some revisions have been merged under it that have not been merged into the reintegration target; merge them first, then retry. I came across a collab.net blog site[1] that referenced this issue. So I tried it in 1.6.6 too, which gave me a little more information - namely, one path in my branch seems to be missing a revision from trunk. In examining the svn:mergeinfo, it seems to be an 'off-by-one' - the svn:merge info records 5627:6031 as being merged but not 5626. I synced the branch using a 1.5.1 client; and running svn diff url-trunk url-branch produces only a delta in the svn:mergeinfo; so I am assuming the files are identical. The merge revision in question adds a folder and file. Reading more of the blog points to a forum[2], and following that I found a post[3] that references doing a record only merge, which I tried (using a 1.6.6 client), but it didn't seem to resolve the 'off-by-one' issue. So, is it: i) safe to just delete the svn:mergeinfo in this case? ii) is is safer/better to just 'svn pedit svn:mergeinfo' to include the extra revision? (e.g. edit 5627:6031 - 5626:6013) Would 'ii' even work? If so, which is (a) better, (b) safer? I kind of lean towards 'i' since (1) it seems to be documented, and (2) the files do seem to be the same. But I'd like to understand this a little more before I do something. TIA, Ben [1]http://blogs.open.collab.net/svn/2008/07/subversion-merg.html [3]http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4dsMessageId=99955
Re: svn:mergeinfo property question...
- Original Message From: Bob Archer bob.arc...@amsi.com frankly... 1.5.1 has many merging bugs in it. I would suggest you upgrade the client to the last 1.5 release or the current 1.6 release. As much as I would like to be able to use a 1.6 client on the system - I can only get 1.5.1 on Kubuntu 8.04 TLS, and that requires using back-ports to do so; otherwise, I'm still limited to 1.4 on that system. So I still need to be able to do the work on that system. Sadly, the backports only has 1.5.1 and nothing newer. I might setup a Kubuntu 10.04 TLS VM do so some work with, but the 8.04 TLS has the environment I need to generate builds from for the time being, so 1.5.1 and 1.4 are sadly with me to stay for a while. That said... I'm not sure you can just reintegrate a branch that existed before merge tracking. If you do you have to make sure to do record only merges from trunk into branch. To reintegrate the branch 100% of the trunk code must have been merged to the branch... (assuming you are reintegrating to trunk.) Yes, it is possible during a merge that mergeinfo is removed. Google for mergeinfo elision. Druing a merge svn will ellide any merge info of child nodes where all the info will reside in a parent node. Thanks. The article Subversion 1.5 Mergeinfo - Understanding the Internals[1] had some really good information, and the section on elision provides some good insight into what is going on. To Quote: In other words, removing the subtree's mergeinfo is safe to do since, if the subtree's mergeinfo is equivalent to its nearest parent with explicit mergeinfo, then the mergeinfo the subtree inherits from that parent is already sufficient to describe the merges to the subtree. It's probably becoming clear now that mergeinfo inheritance and elision are just two ways of looking at the same thing: Inhertance is mergeinfo sliding down the tree from parent to child, elision is mergeinfo sliding up the tree from child to parent. So, the removal is simply b/c it matches trunk and has no other merges to worry about if I understand it correctly, in which case - it's perfectly safe and sane to do. Please correct me if I'm wrong. Ben [1] http://www.collab.net/community/subversion/articles/merge-info.html
Hook Script Examples
My old subversion server had a hookscript to deny commits unless there was a log message. I'd like to setup the same functionality on the new subversion server too. I already got my hook-scripts in place, but... In the process, I came across the following README files: http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/README http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/README both of which references the old tigris.org site: http://subversion.tigris.org/tools_contrib.htmlHoweve, the page is no longer available, and I can't find it on the new apache.org site either. Is this page just simply no longer going to be available? Or is there somewhere else for this stuff now? Ben
Re: Two trunks in one repository?
svn:externals are exactly what you want. Basically, treat PartA and PartB as separate projects entirely - think third party libraries - then your ProjectD just brings together PartA and PartB and adds the glue to concat them together, using svn:externals to bring in the appropriate versions. Your ProjectD trunk could bring the trunks for the PartA and PartB, and branches could bring in the appropriate branches, with tags being locked to specific releases. Though I would suggest that you also lock trunk to specific releases of the externals too, for stability; but that's a project admin's decision. Ben - Original Message From: Geoff Hoffman geoff.hoff...@jawa.com To: users@subversion.apache.org Sent: Thu, September 9, 2010 5:12:52 PM Subject: Re: Two trunks in one repository? SVN won't care, but our IDE may not like it like that. The only reason I brought up svn:externals before is if PartA and PartB are already in SVN as their own repos (or trees under one repo) then ProjectD doesn't want a copy of those projects code, but rather a reference to them. Thus, on ProjectD you'd have svn propset svn:externals PartA ProjectA/tags/tagA1 PartB ProjectB/tags/tagB1 When you commit and update this, new folders appear (PartA and PartB) from svn checkout of tagA1 and tagB1 respectively. Update those tags or change externals to new tag, and your ProjectD gets the update at next svn up. - Original Message - From: Tech Geek techgeek12...@gmail.com To: Erik Andersson kir...@gmail.com Cc: Geoff Hoffman geoff.hoff...@jawa.com, users@subversion.apache.org Sent: Thursday, September 9, 2010 1:23:27 PM Subject: Re: Two trunks in one repository? I am thinking something like this: ProjectD ProjectD/PartA/trunk ProjectD/PartA/tags ProjectD/PartA/branches ProjectD/PartB/trunk ProjectD/PartB/tags ProjectD/PartB/branches Beleive me or not in our scenario the code of Part A and Part B never gets merged at any point. The only common part is that at the end of each release of Part A and Part B their output file is concetenated into a one single file which is then programmed on a hardware part by an external tool. So for a scenario like that I would like to keep it very simple. Any feedback or comments regarding the above structure? Thanks!
Re: Scripting an svn:externals change
- Original Message From: Ryan Schmidt subversion-20...@ryandesign.com $ cat Example1.dump | sed 's/file:\/\/\/svnTest\/Example1/file:\/\/\/svnTest\/Example2/' Example1-edited.dump Do not use sed to edit a dumpfile. Use a tool designed for the task, like svndumptool. http://svn.borg.ch/svndumptool/ Why? B/c it might change data in files too? That's actually something I want done. My prime repository has some scripts in it that store the repository information for auto-checkouts as part of build environments, and I want those changed too - not just the svn:externals. Or would sed 'break' the dump file format? svndumptool does look useful to verify that sed did exactly what I wanted - standard diff won't work well on a 2.1 GB dumpfile. 5. Load the edited dump into a new repository (Example2) $ cd /svnTest $ svnadmin create Example2 $ svnadmin load Example2 Example1-edited.dump Because this repository is now different than it was before (the history has been edited), you must give the new repository a new UUID. svnadmin load --ignore-uuid Example2 Example1-edited.dump I wouldn't say 'must' but 'should' - as in 'highly recommended'. Since the UUID has changed, everyone must check out new working copies; it is not possible to update or switch existing working copies to this new changed repository. Or I could just ignore the history, and just go back to my original question of changing the values. As I said, I need to make this as seamless as possible for everyone - preferably doing an 'svn relocate'/'svn update' on the working copies. Question: If I checked them out again would the client realize that I have a series of files locked and retain the locks on the new working copy? (That would be a PITA to track down if it didn't.) TIA, Ben
Re: Scripting an svn:externals change
- Original Message From: Ryan Schmidt subversion-20...@ryandesign.com To: BRM bm_witn...@yahoo.com Since the UUID has changed, everyone must check out new working copies; it is not possible to update or switch existing working copies to this new changed repository. Or I could just ignore the history, and just go back to my original question of changing the values. As I said, I need to make this as seamless as possible for everyone - preferably doing an 'svn relocate'/'svn update' on the working copies. And as I said, dump and load and changing UUID requires checking out new working copies. You cannot relocate or update existing working copies. If that's too restrictive, then yes, you'll have to skip the dump and load, just change the externals in HEAD, and accept that you can't check out a past revision and have the externals work. Having the history broken is not much of a problem that way. It just would have been nice to have it work well too. Though, couldn't I setup a script to modify the svn:externals via the pset --revprop option? Any how...I've got a lot of work ahead regardless. Question: If I checked them out again would the client realize that I have a series of files locked and retain the locks on the new working copy? (That would be a PITA to track down if it didn't.) I'm not sure exactly what you meant (checked out new working copies? from the new repository?), but note that the dump format does not include information about hook scripts, config files or locks. If you dump and load, the new repository will have the default hook script templates (so, no hook scripts), the default configuration, and nothing locked. But I think you can manually bring the relevant files from the old repository to the new one to preserve this data. Okay - the basic situation is that I have a branch in SVN that was under migration. It was a port of our CVS into SVN and needed to be split up into separate projects which requires a lot of work to do. So I had a working copy where I locked files that I had moved to the new structure to help keep from editing those files in the old structure, and it'll be a PITA to figure out which files were moved and locked between the two. At least I still have the working copy. If they don't transfer, okay - I just have to go through the old working copy and relock them in a new working copy. (I had to use locks as I couldn't just remove the files due to breaking other projects.) Thanks - I think I have my plan of action now - it'll just take a while to implement. If I can get apache to do the proxy thing (http://silmor.de/49) then I can at least get back to a working state where we can move things about with our existing working copies - make sure all changes are in, and are at a good place to re-download them. Sadly this all occurred due to a server crash, so it was rather unplanned though it didn't surprise some of us. Thanks all! Ben
Scripting an svn:externals change
I recently had my subversion server die - the box, not subversion itself - and have been working through the recovery process. Part of that is going through and modifying a number of projects for the change in the URL - namely changing from a non-standard port for apache to a standard port. We have started using svn:externals in some projects, but did not use the relative path values - instead, specifying the whole URL; so I need to update the URLs in the svn:externals. I know I can get the values using 'svn pget svn:externals'; but the SVN redbook recommends against using pset/propset to set the values. So, how do I set the values from a script? svn help pset seems to show a -F parameter for reading the values from a file. This seems like it would take care of the concern mentioned issue - that the externals are multi-line. If that is the case, then shouldn't the note say to use that parameter with pset or use pedit instead of flatly saying use pedit? Or is there another reason why I shouldn't use pset? TIA, Ben http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
Re: Scripting an svn:externals change
- Original Message On Sep 2, 2010, at 11:27, BRM wrote: I recently had my subversion server die - the box, not subversion itself - and have been working through the recovery process. Part of that is going through and modifying a number of projects for the change in the URL - namely changing from a non-standard port for apache to a standard port. We have started using svn:externals in some projects, but did not use the relative path values - instead, specifying the whole URL; so I need to update the URLs in the svn:externals. I know I can get the values using 'svn pget svn:externals'; but the SVN redbook recommends against using pset/propset to set the values. So, how do I set the values from a script? svn help pset seems to show a -F parameter for reading the values from a file. This seems like it would take care of the concern mentioned issue - that the externals are multi-line. If that is the case, then shouldn't the note say to use that parameter with pset or use pedit instead of flatly saying use pedit? Or is there another reason why I shouldn't use pset? If you can afford to have the repository offline, make a dumpfile, twiddle it, load it into a new repository, and have everybody check out new working copies, you may want to consider doing that. The twiddling step would be done with the svndumptool script. The advantage would be that you could correct the externals definitions in all past revisions of the repository too, not just the HEAD, so that anybody needing to check out a past revision would still have working externals in the repository's new location. And do use relative externals this time so you won't have to do this kind of surgery ever again, noting that the relative externals syntax is only compatible with Subversion 1.5 and higher. That's a good thought. I might try doing that tonight. I'm aware of they syntax compat issue, and have no problem saying that we have to use 1.5 or higher; it's just a matter of getting the update through. Ben
Re: Scripting an svn:externals change
- Original Message
From: BRM bm_witn...@yahoo.com
To: Ryan Schmidt subversion-20...@ryandesign.com
- Original Message
On Sep 2, 2010, at 11:27, BRM wrote:
If you can afford to have the repository offline, make a dumpfile,
twiddle
it, load it
into a new repository, and have everybody check out new working copies,
you
may
want to consider doing that. The twiddling step would be done with the
svndumptool
script. The advantage would be that you could correct the externals
definitions in all
past revisions of the repository too, not just the HEAD, so that anybody
needing to
check out a past revision would still have working externals in the
repository's new
location. And do use relative externals this time so you won't have to do
this kind
of surgery ever again, noting that the relative externals syntax is only
compatible
with Subversion 1.5 and higher.
That's a good thought. I might try doing that tonight. I'm aware of they
syntax
compat issue, and have no problem
saying that we have to use 1.5 or higher; it's just a matter of getting the
update through.
Okay - well, I decided to try this route, but was advised to try it on a test
repository first.
Good thing - as there is a bit of an issue, and one I need to avoid if I can...
The issue is that an existing working copy's externals are not being updated
when 'svn update' runs,
even though the externals have changed on the server through the update.
Here's my test:
1. Create a file-based repository:
$ cd /
$ mkdir svnTest cd svnTest
$ svnadmin create Example1
$ mkdir -p ~/testsvn cd ~/testsvn
$ export SVNROOT=/svnTest
$ svn co ${SVNROOT}/Example1 example1.wc
$ cd example1.wc
$ mkdir sub1 sub2
$ svn add sub1 sub2
$ svn commit -m Adding some structure for test
$ touch sub1/file1
$ svn add sub1/file1
$ svn commit -m Adding a file for test
$ svn pedit svn:externals sub2
set the svn:externals to:
sub2a file:///svnTest/Example1
save and quit
$ svn update
$ svn commit -m Adding an external for test
2. Make a backup of the working copy
$ cd ~/testsvn
$ tar -jcvvf example1.wc.tar.bz2 example1.wc
3. Dump the repository
$ cd /svnTest
$ svnadmin dump Example1 Example1.dump
4. Switch the external reference from Example1 to Example2
$ cat Example1.dump | sed
's/file:\/\/\/svnTest\/Example1/file:\/\/\/svnTest\/Example2/'
Example1-edited.dump
5. Load the edited dump into a new repository (Example2)
$ cd /svnTest
$ svnadmin create Example2
$ svnadmin load Example2 Example1-edited.dump
6. Rename the Example1 repository so it looks like it was removed
$ cd /svnTest
$ mv Example1 Example1.removed
7. Relocate the Example1 working copy, then update it
$ cd ~/testsvn
$ cd example1.wc
$ svn switch --relocate file:///svnTest/Example1 file:///svnTest/Example2
$ svn update
At this point 'svn update' fails outright complaining that it cannot find
file:///svnTest/Example1 (since it was removed).
So I can live with sub2a not getting updated without an svn switch --relocate
occurring on it - integrity and all; however, I would have expected that
svn update the svn:externals on sub2. I could even live with having to rename
an existing external (sub2a - sub2a.orig) and updating (it's kinda of
acceptable, but not ideal).
At this point, I would expect that the svn:externals property for 'sub2' match
what is in the Example2 repository.
However, an 'svn pget svn:externals sub2' reveals that it did not get updated.
I even tried 'svn update --force'.
I kind of expected that 'svn update --ignore-externals' would not update it
either - which is what I found when I tried it.
Now I tried this with a 1.5.1 and 1.6.6 versions of the svn toolchain; though
if
it is working in something newer okay. However, I'm kind of stuck with those
two
versions - ubuntu hardy-backports provides 1.5.1 and lucid uses 1.6.6.
Now why is this a big issue for me? B/c I and a number of my team members
have a lot of projects with svn:externals, and we need to update our working
copies.
I need to make this as seamless as possible. Scripting the svn switch
--relocate command is easy; but I shouldn't have to also edit the
svn:externals
on each project
since that was already changed in the repository.
Now I may be able to alleviate my issue some through temporarily restoring an
alternate port that gets redirected to the server via proxy[1] (the old server
ran on example.com:82 and the new one is on example.com); but forcing people
to
have to completely delete their working copies is not an easy option -
especially since there may be some changes in the working copies that have not
yet made it to the server.
Or am I missing some? At this point, I am not going to touch my primary
repository until I know the right solution - but that also means we're stuck.
TIA,
Ben
[1]http://silmor.de/49
Re: Mailing lists? Really?
- Original Message Certainly not. Nor do you have to subscribe to post. As a non-subscriber your post will be moderated but if you are patient it will be approved through fairly quickly (says I as one of the moderators). And indeed, I started this thread without subscribing. But I still can't find a way to respond to an existing message without first having that message in my inbox. That's my main problem. I just opened groups.google.com, and then searched for subversion. Both the subversion-dev and subversion users lists came up at the top. Here's the users: http://groups.google.com/group/subversion_users?lnk=srg And even this thread: http://groups.google.com/group/subversion_users/browse_thread/thread/b87e732b8a47420f Note that there is also a way to post to the list via this interface's + new post button. I didn't join the group through that interface, but it seems that the new post button makes you join the group before you can post. It has a nifty forward feature gmail style already there regardless, and I'm guessing you will get the reply after joining the group. HTH, Ben
Re: truMerge 1.1.0 released
Checked out the website, and there doesn't seem to be much up on truMerge; it took me a while to find out it needs the command-line 1.5 series client to function. More info on the website would be useful - especially requirements, supported platforms, a working Wiki, etc. (No, I didn't log into open.collab.net; but I shouldn't have to to find out that information either.) I did eventually find some of the info in the INSTALL doc, but it took me a while to even find that. Any how...all that aside... Question: Does it require a 1.5 series or later SVN server? Or can it make due with older servers? TSVN requires a Merge tracking enabled SVN server to be able to do merges. Right now, I don't have access to one - my server is 1.4 series and I can't change it right now (external limitations). So if you can work with an older server without the merge tracking info then I'm more than happy to try a few merges with it and see how things go. If not, please add that to the documentation too. Thanks, Ben - Original Message From: Stefan Sperling s...@elego.de To: users@subversion.apache.org Sent: Wed, May 26, 2010 8:27:10 AM Subject: Re: truMerge 1.1.0 released On Wed, May 26, 2010 at 12:17:38AM +0200, Schellingerhout, Nico wrote: Dear Subversion users, I am happy to announce the release of truMerge 1.1.0. truMerge is a merge helper tool that combines true renamehttp://subversion.tigris.org/merge-tracking/requirements.html functionality with Subversion merge, in order to handle tree conflicts more reliably and effectively. truMerge not only recognizes but also handles most tree conflicts automatically. I would like to encourage all users who regularly encounter tree conflicts to try trumerge and let the community know their opinion on its behaviour (regarding performance as well as perceived correctness of tree conflict resolution). The behaviour of trumerge will likely be a role-model for Subversion when we get around to further improving tree conflict detection and resolution in the post-1.7 era. So you will help Subversion by providing feedback about trumerge. Thanks, Stefan
Re: Managing Vendor Branches
- Original Message From: Jeff Mott jeff.mott...@gmail.com I've recently needed to track changes for vendor code drops, so I read the SVN book's vendor branches chapter. But I'm not entirely happy with part of the procedure, so I'd like to talk it out and, I hope, find a better way. The part I hope to improve is when I have a versioned code drop in the /vendor directory, then the vendor provides a new code drop. The SVN book suggests that I should copy the new files over top of the files in my working copy. Then I need to SVN add and delete as needed. I saw there's a script to ease this process, but I still feel that this should be easier. It seems to me that comparing two trees, even unrelated trees, is something SVN is very good at. So if I have /vendor/code-drop-v1 and /vendor/code-drop-v2, then it seems SVN should be able to derive the changes between the two and apply those changes to my working copy. Can I do this? Here's what I do: In my repository I have a ThirdParty namespace (e.g. /ThirdParty) under which each Third-Party import has their own namespace (e.g. /ThirdParty/import/), with each having its own 'trunk', 'branches', and 'tags'. When I import a new version, it goes into the 'branches'. This then gets merged to 'trunk', and released to 'tags'. My projects then pull against the 'tag' using svn:externals. In this way, I can track the changes that happen from the vendor and even accept or deny some changes if I need to. For example, Qt has a niced add-on for supporting services/daemons - the Qt Service Class (http://doc.trolltech.com/solutions/qtservice/qtservice.html). However, their releases of it are targeted either at Windows OR Unix/Linux/Mac, but I need to support both; so using this method I merge them both together and use the merged result in my source. Personally, I think this helps as it is basically treating the vendor as another project in the repository. Of course, each of my projects have their own trunk/branches/tags, so this might not work for you if you're not doing that too...but you could probably find similar way. HTH, Ben
