Re: mergeinfo not inherrited when I thought it should
On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert wrote: > Hello, > > Here is some more information: > >>> Inside branch1/subfolder, we do a merge from trunk/subfolder. >> >> Do you mean trunk/project/subfolder here? > > yes > >> Anyway, branch1/subfolder does not have any mergeinfo, >> since the previous merge was done on branch1. So Subversion >> does not know that you have already merged the changes to line 1. > > Correct, but isn't SVN supposed to crawl up the tree to find > mergeinfo? I thought this was the most simple usecase of inherited > mergeinfo, which is described in various places, for instance here: > http://help.collab.net/index.jsp?topic=/faq/mergeinfo.html Yes, you are absolutely right. Mergeinfo is normally inherited, so any mergeinfo set on the branch1 folder applies to the entire subtree (and svn indeed crawls up the tree to find all the mergeinfo that applies). Except if the mergeinfo is marked with an asterisk '*', which means "non-inheritable mergeinfo". For more in-depth information about mergeinfo, see [1]. >> Merges from trunk to branch and vice-versa should always be done >> from the root of the project (in your case branches/project/branch1) > > I can not believe this is true. I can not control the other users and > I have had reports of similar issues from a few different users here, > so it seems a real use case. Well, it's *recommended* to do merges always from the project root, but it's not required. SVN supports so-called "subtree merges" (which have the potential to only merge part of a revision). The reason it's recommended to do merges from the project root, is that it avoids explicit mergeinfo all over your tree. For every subtree merge, SVN records explicit mergeinfo on that subtree root. This means that that subtree will no longer inherit mergeinfo from higher up the tree. For this reason, explicit mergeinfo needs to be maintained all the time by SVN (because it will no longer crawl up from that point). Every subsequent merge at the project root causes those explicit-mergeinfo-paths to have their mergeinfo properties updated, even if they are not affected by the merge, which can be quite confusing to users. Other than that, subtree merges work just fine in SVN, just because of the explicit mergeinfo on the subtrees. (the upcoming 1.7 release will improve the situation a bit, IIUC: the not-affected-subtrees will no longer have their mergeinfo updated all the time, only if they are affected by the merge). >> I don't think so, as I think Subversion did the correct thing, given the >> information it has. > > Well, I still think it did not do the correct thing, as it had more > info available than it actually used. > >> However, I recommend you to push for an upgrade of SVN, as I remember 1.5 >> was not particularly good with merging. > > I have just tested with 1.6.13 on a test pc and it behaves exactly the same. > > > > By reading the details of inherited mergeinfo in the collabnet FAQ, > maybe the bug is because mergeinfo is not up to date in the working > copy and SVN uses that instead of contacting the repository. If this > is the case, I would expect SVN to give me a "please update" warning > when I do the merge command. Yes, maybe that's the problem. Can you retest this with an update at the right place, to see if the problem still occurs? Maybe you should check out the section "Mixed Revision Working Copies and Mergeinfo" in the above mentioned article [1], to see if it describes what you're seeing. If that's the case, you are probably right about the warning. I think this is being addressed in the upcoming 1.7 as well (see [2] and [3]). If the problem is something else, please try to come up with a simple reproduction recipe, starting with the creation of an empty repository (svnadmin create ...), demonstrating the problem. Cheers, -- Johan [1] http://www.collab.net/community/subversion/articles/merge-info.html [2] http://svn.haxx.se/dev/archive-2010-10/.shtml [3] http://svn.apache.org/viewvc?view=revision&revision=1027970
Inaccurate "Updated to revision" when updating multiple targets
Minor bug report in the way Subversion prints output when I'm updating multiple
targets, some of which have changes and some of which do not.
Imagine I have directories a, b and c, and I ask Subversion to update all
three, but only b has changes. The output received with Subversion 1.6.13 on
Mac OS X 10.6.4 is:
$ svn up a b c
At revision 2.
Ab/something
Updated to revision 2.
Updated to revision 2.
$
The expected output is:
$ svn up a b c
At revision 2.
Ab/something
Updated to revision 2.
At revision 2.
$
Looking in subversion/svn/notify.c it looks like it prints "Updated to" or "At"
depending on whether nb->received_some_change, so that variable should be reset
when moving to a new target.
The reproduction recipe is:
$ svnadmin create repo
$ REPO=file://$PWD/repo
$ svn mkdir $REPO/{a,b,c} -m x
Committed revision 1.
$ svn co $REPO wc
Awc/a
Awc/b
Awc/c
Checked out revision 1.
$ cd wc
$ svn up a b c
At revision 1.
At revision 1.
At revision 1.
$ svn mkdir $REPO/b/something -m x
Committed revision 2.
$ svn up a b c
At revision 2.
Ab/something
Updated to revision 2.
Updated to revision 2.
$ svn up a b c
At revision 2.
At revision 2.
At revision 2.
$
svn forgets authentication password
Hi I am running svn command line client 1.6.13 on Linux. Recently (possibly since upgrading from 1.6.6 to 1.6.13) I have found that whenever I run: svn up I am prompted for my password. I then choose to save it (unencrypted) but next time around I am prompted for it again. Any idea why this might be please? David
Re: German translation of "svn help st" is not showing, although provided in de.po
Paul Maier wrote on Wed, Nov 03, 2010 at 07:33:32 +0100: > Hello, > > Obverved: > All svn output, error messages, online help comes in German. > But "svn help status", "svn help switch" and "svn help update" > print in English. > > Expected: > "svn help status", "svn help switch" and "svn help update" > should print in German. > > The translation exists in the repository: > http://svn.apache.org/repos/asf/subversion/trunk/subversion/po/de.po, > lines 9493 - 9587 (svn help status), First, this is trunk and not /branches/1.6.x or /tags/1.6.13. Second, it's possible that the message has been updated but not the translation. Based on your description (all messages --- including Subversion-specific message strings --- are in German, except these three), I suspect that is the case. There's not much you can do, other than get someone to update the translations --- or jumping in and doing that yourself! Daniel (there is a "Translations" top-level section in the Community Guide that explains how you can help (if you want to)) > lines 9626 - 9667 (svn help switch) and > lines 9723 - 9769 (svn help update). > > These are the binaries I use: > http://alagazam.net/svn-1.6.13/Setup-Subversion-1.6.13.msi > > Thank you for having a look into that. > > Greetings, > Paul. > >
Re: Inaccurate "Updated to revision" when updating multiple targets
Ryan Schmidt wrote on Wed, Nov 03, 2010 at 04:48:21 -0500: > Minor bug report in the way Subversion prints output when I'm updating > multiple targets, some of which have changes and some of which do not. > > Imagine I have directories a, b and c, and I ask Subversion to update > all three, but only b has changes. The output received with Subversion > 1.6.13 on Mac OS X 10.6.4 is: > > > $ svn up a b c > At revision 2. > Ab/something > Updated to revision 2. > Updated to revision 2. > $ > Same with trunk: % $svn up A mu B At revision 2. U mu Updated to revision 2. Updated to revision 2. > > The expected output is: > > > $ svn up a b c > At revision 2. > Ab/something > Updated to revision 2. > At revision 2. > $ > +1 > > Looking in subversion/svn/notify.c it looks like it prints "Updated > to" or "At" depending on whether nb->received_some_change, so that > variable should be reset when moving to a new target. > +1. (Or should the 'received_some_change' logic live in the library (in the generation of notifications)? I haven't thought much about that.) > Bottom line: agreed that there is a bug here. If you (or anyone else) wants to file an issue or send a patch for that, go ahead. :-)
simple question on branching
We don't often use branching and/or merging based on the simple nature of our version releases with very little overlap. We have a longer ranging version - the next 7 months or so in progress. Since we are getting ready to deliver some file changes I'd like to use the trunk instead of a branch just because it's easier. There is a very little chance we would really need to release anything to the previous production level during these 7 months. If it came up I was going to just copy the tag to a branch and use that for development - and basically tagging it (or maybe even merging into the tag). Any reason that creating a permanent branch on the tree would matter -- i mean never merging it anywhere? I don't see what harm it would have really - but I just wanted to be sure in case I decide to branch from the production version of the trunk instead. Probably a silly question - but it's good to have input from others who branch and merge regularly. Thx for any help. If it matters - we are still on svn 1.4.3. KM
Log problem
Hi, I've run over a strange situation and want to know if this is OK to happen (in my opinion it shouldn't). These are the details: - one of our servers has a repository with Subversion 1.4 format - I have a working copy from a given repository path, let it be "http://R/svn/repos/userguide"; - in my working copy, one of the folders has an external folder X, pointing to "http://R/svn/repos/branches/rel/doc"; - I modify a file from the external folder X and commit it - when looking over the log information of the root of my working copy, there is no entry for the commit which I've just made (this is OK, I've committed to an external resource) - after, I look over the log information of the folder at which my working copy external folder targets. There is no information about my commit there either, which is strange, I've committed from my external folder which is pointing to this one. - the folder to which my working copy external folder is pointing was copied from another branch, and if I do a log on that branch (the original one), then I can see my commit, which again is strange: why the commit goes there and not to the HEAD of the branch to which my external folder is pointing. I don't know if the above information helps you somehow, but I would like to know if this would be possible and if this is a repository side problem, taking into account that the repository has an old version (1.4). Thank you. Best Regards, Florin
Re: Log problem
On Nov 3, 2010, at 05:54, Florin Avram wrote: > I've run over a strange situation and want to know if this is OK to happen > (in my opinion it shouldn't). These are the details: > - one of our servers has a repository with Subversion 1.4 format > - I have a working copy from a given repository path, let it be > "http://R/svn/repos/userguide"; > - in my working copy, one of the folders has an external folder X, pointing > to "http://R/svn/repos/branches/rel/doc"; > - I modify a file from the external folder X and commit it > - when looking over the log information of the root of my working copy, there > is no entry for the commit which I've just made (this is OK, I've committed > to an external resource) > - after, I look over the log information of the folder at which my working > copy external folder targets. There is no information about my commit there > either, which is strange, I've committed from my external folder which is > pointing to this one. Is the folder up to date? Use "svn up" and try again. > - the folder to which my working copy external folder is pointing was copied > from another branch, and if I do a log on that branch (the original one), > then I can see my commit, which again is strange: why the commit goes there > and not to the HEAD of the branch to which my external folder is pointing. > > I don't know if the above information helps you somehow, but I would like to > know if this would be possible and if this is a repository side problem, > taking into account that the repository has an old version (1.4). I doubt any problem exists.
Re:
2010/11/3 Cédric Louboutin > Why are the folder containing external files and the external files modified > when I merge some revision from trunk to branch ? Knowing that the trunk > revision does not include any modifications on these files. > > Regards. > > Server information : > OS : Windows 2003 server 32 bits > SVN server program: CollabNetSubversion-server-1.6.13-1.win32.exe > > Client information: > OS: Windows Vista 64 bits > SVN client program: TortoiseSVN-1.6.11.20210-x64-svn-1.6.13.msi I don't understand what you are asking. Can you explain in more detail what happened, and what you expected to happen instead? Can you explain with a concrete example (feel free to "obfuscate" paths and other sensitive stuff)? Cheers, -- Johan
Re: mergeinfo not inherrited when I thought it should
Hi, I tested with a reproduction scenario and found this: A) If I do an svn update on the top-level WC before the merge command, the merge goes through OK and I can checkin. B) If I don't do an svn update on the top-level WC before the merge command, the merge goes wrong and svn complains about out-of-date when I do the checkin. A following svn update seems to not change anything and I can checkin the wrong merge without problems. There are a few things still not clear to me: 1) Before this svn update, svn stat -u shows nothing out-of-date, so it's strange that an update makes any difference. 2) svn update itself does not mention any updates, it just says "At revision 6." 3) If I check the relevant svn:mergeinfo properties before / after this svn update, I see no changes at all. However, if I check with the svn mergeinfo command, then I do see a change after the update. What else is being used to calculate the actual mergeinfo? 4) If I don't do the update before svn merge, why does svn complain about out-of-date at checkin instead of at the merge itself? See attachment for reproduction script + output for both cases. Kind regards and thanks for the help, Pieter-Jan On 3 November 2010 10:17, Johan Corveleyn wrote: > On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert > wrote: >> Hello, >> >> Here is some more information: >> Inside branch1/subfolder, we do a merge from trunk/subfolder. >>> >>> Do you mean trunk/project/subfolder here? >> >> yes >> >>> Anyway, branch1/subfolder does not have any mergeinfo, >>> since the previous merge was done on branch1. So Subversion >>> does not know that you have already merged the changes to line 1. >> >> Correct, but isn't SVN supposed to crawl up the tree to find >> mergeinfo? I thought this was the most simple usecase of inherited >> mergeinfo, which is described in various places, for instance here: >> http://help.collab.net/index.jsp?topic=/faq/mergeinfo.html > > Yes, you are absolutely right. Mergeinfo is normally inherited, so any > mergeinfo set on the branch1 folder applies to the entire subtree (and > svn indeed crawls up the tree to find all the mergeinfo that applies). > Except if the mergeinfo is marked with an asterisk '*', which means > "non-inheritable mergeinfo". For more in-depth information about > mergeinfo, see [1]. > >>> Merges from trunk to branch and vice-versa should always be done >>> from the root of the project (in your case branches/project/branch1) >> >> I can not believe this is true. I can not control the other users and >> I have had reports of similar issues from a few different users here, >> so it seems a real use case. > > Well, it's *recommended* to do merges always from the project root, > but it's not required. SVN supports so-called "subtree merges" (which > have the potential to only merge part of a revision). > > The reason it's recommended to do merges from the project root, is > that it avoids explicit mergeinfo all over your tree. For every > subtree merge, SVN records explicit mergeinfo on that subtree root. > This means that that subtree will no longer inherit mergeinfo from > higher up the tree. For this reason, explicit mergeinfo needs to be > maintained all the time by SVN (because it will no longer crawl up > from that point). Every subsequent merge at the project root causes > those explicit-mergeinfo-paths to have their mergeinfo properties > updated, even if they are not affected by the merge, which can be > quite confusing to users. Other than that, subtree merges work just > fine in SVN, just because of the explicit mergeinfo on the subtrees. > > (the upcoming 1.7 release will improve the situation a bit, IIUC: the > not-affected-subtrees will no longer have their mergeinfo updated all > the time, only if they are affected by the merge). > >>> I don't think so, as I think Subversion did the correct thing, given the >>> information it has. >> >> Well, I still think it did not do the correct thing, as it had more >> info available than it actually used. >> >>> However, I recommend you to push for an upgrade of SVN, as I remember 1.5 >>> was not particularly good with merging. >> >> I have just tested with 1.6.13 on a test pc and it behaves exactly the same. >> >> >> >> By reading the details of inherited mergeinfo in the collabnet FAQ, >> maybe the bug is because mergeinfo is not up to date in the working >> copy and SVN uses that instead of contacting the repository. If this >> is the case, I would expect SVN to give me a "please update" warning >> when I do the merge command. > > Yes, maybe that's the problem. Can you retest this with an update at > the right place, to see if the problem still occurs? > > Maybe you should check out the section "Mixed Revision Working Copies > and Mergeinfo" in the above mentioned article [1], to see if it > describes what you're seeing. > > If that's the case, you are probably right about the warning. I think > this is being addressed in the upcoming 1.7 a
Re: XML document structures must start and end within the same entity
On Thu, Oct 28, 2010 at 3:09 PM, Daniel Shahaf wrote: > David Aldrich wrote on Wed, Oct 27, 2010 at 15:48:40 +0100: >> Hi >> >> Please will someone explain the following error message that I received >> while updating a working copy? >> >> "XML document structures must start and end within the same entity." >> Best regards >> David Huh? Was this mail supposed to contain an answer, Daniel? If not, my immediate response would be: this question contains too little information for most people on this list to be able to help out (I think). Can you give more information about the exact commands which you executed, does this happen always or only sometimes, under particular circumstances, is the working copy broken after this error, what happens if you retry it, ...? Cheers, -- Johan
Re: simple question on branching
On Wed, Nov 3, 2010 at 9:44 AM, KM wrote: > > We don't often use branching and/or merging based on the simple > nature of our version releases with very little overlap. > > Any reason that creating a permanent branch on the tree would matter > -- i mean never merging it anywhere? I don't see what harm it would > have really - but I just wanted to be sure in case I decide to branch > from the production version of the trunk instead. Anyone will tell you that branching and merging is hell, and if you can avoid it, you avoid it. The standard is to keep branching to a minimum and only do it when necessary. There are really two main reasons to branch: Reason #1: You are about to do a release, and want to avoid developers twiddling their thumbs as you do a code freeze. Branching allows some developers to clean up the code on the branch and release from the branch while other developers continue working on the trunk. Reason #2: You are working on a new revision when a bug was found on an older revision, and you want to fix that bug before the new revision comes out. Of course, if you branched for Release #1, you already have the branch you need for that bug fix. Open source projects rarely branch. If you find a bug, they simply tell you to wait for the next release (which probably comes every few months). If you really must have the fix now, you grab either the trunk source code where the fix might already be implemented or the release source code and fix the problem yourself. Nor, do open source projects care about keeping developers occupied while they try to prep the code for a release. After all, they don't pay the developers, so they don't care if the developers have nothing to do. If you don't need to branch, then don't branch. I've worked on many projects which almost never branched and others that loved diagramming complex branching schemes. (Release 1.0.1 branched from the Release 1.0.X branch which branched from the Release 1.0 branch which branched from the Release 1.X branch.). I will tell you that ones that never branched had better development and fewer problems. So, if you don't need to branch, you're fine. And, if you do need to fix a bug on a release, you can always branch from the tag and fix the bug on that branch. (Or, you can find the revision that created the tag and simply branch off the trunk from that revision.) What ever you do, don't change your tags. Tags are suppose to be snapshots of what took place and should be absolutely stable. When the sun explodes into a fiery ball and destroys all life on Earth, any alien being who lands on the Earth's charred remains and finds your source repository should see the same set of files tagged as REL-1.0.1 that you did the day you created that REL-1.0.1 tag. -- David Weintraub qazw...@gmail.com
Re: XML document structures must start and end within the same entity
Johan Corveleyn wrote on Wed, Nov 03, 2010 at 15:23:51 +0100: > On Thu, Oct 28, 2010 at 3:09 PM, Daniel Shahaf > wrote: > > [empty reply] > > Huh? Was this mail supposed to contain an answer, Daniel? > No; it was accidentally sent.
Re: mergeinfo not inherrited when I thought it should
Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100: > (the upcoming 1.7 release will improve the situation a bit, IIUC: the > not-affected-subtrees will no longer have their mergeinfo updated all > the time, only if they are affected by the merge). That surprised me a little, but a quick test with current trunk[1] confirms: % cd ~/src/svn/16x/ % $svn merge -c N ../trunk ... % $svn pg -vR svn:mergeinfo . | grep Properties Properties on '.': Properties on 'subversion/tests/cmdline/merge_tests.py': Properties on 'CHANGES': % $svn st -q M . M subversion/include/svn_client.h C subversion/tests/cmdline/export_tests.py C subversion/svn/export-cmd.c M subversion/libsvn_client/export.c % $svn st -q | egrep 'CHANGES|merge_tests' % Nice. Daniel [1] I'm using a build from the performance branch as my "current trunk" build these days.
Re: mergeinfo not inherrited when I thought it should
On Wed, Nov 3, 2010 at 3:45 PM, Daniel Shahaf wrote: > Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100: >> (the upcoming 1.7 release will improve the situation a bit, IIUC: the >> not-affected-subtrees will no longer have their mergeinfo updated all >> the time, only if they are affected by the merge). > > That surprised me a little, but a quick test with current trunk[1] > confirms: Yes, it's kind of easy to miss, because there is no explicit issue in the issue tracker for this AFAIK. But I vaguely remember some mail threads on the dev-list about this, and saw it mentioned in the description of another issue about mergeinfo ([1]). This refers to revision r878767 ([2]), which is apparently the reintegration of a feature branch "subtree-mergeinfo", which was made specifically for developing this feature. Since this is quite a big issue for a lot of users, it's important not to forget about this change when the time comes to write the release notes for 1.7. Maybe it should be mentioned on the roadmap page (as one of the finished items), or an issue should be created in the issue tracker? Cheers, -- Johan [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3577 [2] http://svn.apache.org/viewvc?view=revision&revision=878767
Re: simple question on branching
Thanks. My sentiments exactly. Never branch really - and... I probably will not branch for this either !! And yes... so far of course I have never changed a tag of the version released to the field and don't really plan to. I'll make another if necessary. Just trying to think ahead in case. --- On Wed, 11/3/10, David Weintraub wrote: From: David Weintraub Subject: Re: simple question on branching To: "KM" Cc: "svn-apache-users-list" Date: Wednesday, November 3, 2010, 10:36 AM On Wed, Nov 3, 2010 at 9:44 AM, KM wrote: > > We don't often use branching and/or merging based on the simple > nature of our version releases with very little overlap. > > Any reason that creating a permanent branch on the tree would matter > -- i mean never merging it anywhere? I don't see what harm it would > have really - but I just wanted to be sure in case I decide to branch > from the production version of the trunk instead. Anyone will tell you that branching and merging is hell, and if you can avoid it, you avoid it. The standard is to keep branching to a minimum and only do it when necessary. There are really two main reasons to branch: Reason #1: You are about to do a release, and want to avoid developers twiddling their thumbs as you do a code freeze. Branching allows some developers to clean up the code on the branch and release from the branch while other developers continue working on the trunk. Reason #2: You are working on a new revision when a bug was found on an older revision, and you want to fix that bug before the new revision comes out. Of course, if you branched for Release #1, you already have the branch you need for that bug fix. Open source projects rarely branch. If you find a bug, they simply tell you to wait for the next release (which probably comes every few months). If you really must have the fix now, you grab either the trunk source code where the fix might already be implemented or the release source code and fix the problem yourself. Nor, do open source projects care about keeping developers occupied while they try to prep the code for a release. After all, they don't pay the developers, so they don't care if the developers have nothing to do. If you don't need to branch, then don't branch. I've worked on many projects which almost never branched and others that loved diagramming complex branching schemes. (Release 1.0.1 branched from the Release 1.0.X branch which branched from the Release 1.0 branch which branched from the Release 1.X branch.). I will tell you that ones that never branched had better development and fewer problems. So, if you don't need to branch, you're fine. And, if you do need to fix a bug on a release, you can always branch from the tag and fix the bug on that branch. (Or, you can find the revision that created the tag and simply branch off the trunk from that revision.) What ever you do, don't change your tags. Tags are suppose to be snapshots of what took place and should be absolutely stable. When the sun explodes into a fiery ball and destroys all life on Earth, any alien being who lands on the Earth's charred remains and finds your source repository should see the same set of files tagged as REL-1.0.1 that you did the day you created that REL-1.0.1 tag. -- David Weintraub qazw...@gmail.com
Re: mergeinfo not inherrited when I thought it should
Johan Corveleyn wrote on Wed, Nov 03, 2010 at 17:18:54 +0100: > On Wed, Nov 3, 2010 at 3:45 PM, Daniel Shahaf wrote: > > Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100: > >> (the upcoming 1.7 release will improve the situation a bit, IIUC: the > >> not-affected-subtrees will no longer have their mergeinfo updated all > >> the time, only if they are affected by the merge). > > > > That surprised me a little, but a quick test with current trunk[1] > > confirms: > > Yes, it's kind of easy to miss, because there is no explicit issue in > the issue tracker for this AFAIK. But I vaguely remember some mail > threads on the dev-list about this, and saw it mentioned in the > description of another issue about mergeinfo ([1]). There's quite a bit of traffic about mergeinfo. I try to follow the developments to some degree, but I missed (or forgot) about this change. > This refers to > revision r878767 ([2]), which is apparently the reintegration of a > feature branch "subtree-mergeinfo", which was made specifically for > developing this feature. > Thanks for the digging! > Since this is quite a big issue for a lot of users, it's important not > to forget about this change when the time comes to write the release > notes for 1.7. Maybe it should be mentioned on the roadmap page (as > one of the finished items), or an issue should be created in the issue > tracker? > (without expressing an opinion as to which option is preferable,) another option is to create a stub section in /site/publish/docs/release-notes/1.7.html. btw, I think there have been more release-notes-worthy merge-tracking changes than just this one. > Cheers, > -- > Johan > > [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3577 > [2] http://svn.apache.org/viewvc?view=revision&revision=878767
Re: simple question on branching
On Wed, Nov 3, 2010 at 09:44, KM wrote: > > We don't often use branching and/or merging based on the simple nature of our > version releases with very little overlap. We have a longer ranging version > - the next 7 months or so in progress. Since we are getting ready to > deliver some file changes I'd like to use the trunk instead of a branch just > because it's easier. > > There is a very little chance we would really need to release anything to the > previous production level during these 7 months. If it came up I was going to > just copy the tag to a branch and use that for development - and basically > tagging it (or maybe even merging into the tag). > > Any reason that creating a permanent branch on the tree would matter -- i > mean never merging it anywhere? I don't see what harm it would have really > - but I just wanted to be sure in case I decide to branch from the > production version of the trunk instead. > > Probably a silly question - but it's good to have input from others who > branch and merge regularly. > Thx for any help. If it matters - we are still on svn 1.4.3. A "permanent branch" with no merging sounds more like a fork than a branch - a snapshot of your project at a moment in time, then it continues on its own independent development path. Shouldn't be any issues from a technical perspective, it just might get difficult to manage if at some point you do need to merge between the 2 forks.
Trying to build Subversion on Visual Studio 2008
Hello, I'm trying to build Subversion on VS2008 but am missing something. Could I get some pointers please? What I've done so far (based on the instructions in the INSTALL text file in src-trunk) is: *Downloaded an SVN client *Checked out src-trunk ( svn co https://svn.apache.org/repos/asf/subversion/trunk src-trunk ) into C:\SVN *Downloaded subversion-deps-1.6.13.zip and distributed its contents into C:\SVN *Downloaded and installed other mandatory prerequisites but none of the optional ones. *Set up my environment variables in a VS2008 command prompt *Converted the Apache/APR .dsp files to .vcproj I haven't tried to build Apache 2 because it looks like the command requires the optional prerequisites which I haven't downloaded (e.g. the Berkeley stuff and the openssl stuff). When I get to trying to run Visual Studio's command line (devenv) I can't locate the subversion_vcnet.sln file, nor the earlier subversion_msvc.dsw file. What step(s) have I missed? Any help gratefully received. Thanks, Ray. This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
Re: Trying to build Subversion on Visual Studio 2008
PGSEM Contractor 4 wrote on Wed, Nov 03, 2010 at 17:01:30 +: > When I get to trying to run Visual Studio's command line (devenv) I can't > locate the subversion_vcnet.sln file, nor the earlier subversion_msvc.dsw > file. > > What step(s) have I missed? > Running gen-make.py.
Re: simple question on branching
On 11/3/2010 11:56 AM, Andy Levy wrote: On Wed, Nov 3, 2010 at 09:44, KM wrote: We don't often use branching and/or merging based on the simple nature of our version releases with very little overlap. We have a longer ranging version - the next 7 months or so in progress. Since we are getting ready to deliver some file changes I'd like to use the trunk instead of a branch just because it's easier. There is a very little chance we would really need to release anything to the previous production level during these 7 months. If it came up I was going to just copy the tag to a branch and use that for development - and basically tagging it (or maybe even merging into the tag). Any reason that creating a permanent branch on the tree would matter -- i mean never merging it anywhere? I don't see what harm it would have really - but I just wanted to be sure in case I decide to branch from the production version of the trunk instead. Probably a silly question - but it's good to have input from others who branch and merge regularly. Thx for any help. If it matters - we are still on svn 1.4.3. A "permanent branch" with no merging sounds more like a fork than a branch - a snapshot of your project at a moment in time, then it continues on its own independent development path. Shouldn't be any issues from a technical perspective, it just might get difficult to manage if at some point you do need to merge between the 2 forks. I think it is fairly common to always copy trunk->branch-tag for everything that you might consider to be a release, where the branch would be used for any pre-release QA testing you might do and serve as the place for any release-maintenance changes needed for that release. Those changes might or might not be relevant to the trunk - or might already be present in the trunk by the time you decide to backport to the already released version so it is hard to generalize about merges there. If you do make changes, you should then copy to a new tag as you finalize the update so you have human-friendly names to track the released versions. -- Les Mikesell lesmikes...@gmail.com
Re: simple question on branching
On Wed, Nov 3, 2010 at 12:56 PM, Andy Levy wrote: > On Wed, Nov 3, 2010 at 09:44, KM wrote: > A "permanent branch" with no merging sounds more like a fork than a > branch. It's pretty common, really. You're about to do a release, so you make a release branch. In many sites, they don't bother merging changes from the release branch back to the trunk. If a bug is found on the release branch, the release team merely reports it to the trunk team who may simply fix the bug without merging. Of course, if no bugs are found on the release branch that are relevant to the trunk, no merging will be done at all. Once the release is out, that branch may never be used again. It just sits there until someone one day decides to delete it. It's not a fork because all of the code on it is already on the trunk. It's just a dead end branch. -- David Weintraub qazw...@gmail.com
Can you hear me now?
Hi, I tried posting a question to this users list last night and I still don't see it here (nor any responses). Am I being blocked? Am I being too impatient? Will I simply not see my own posts until someone replies? I think the same thing happened to me on the last couple questions I posted here, a few months back. According to http://subversion.apache.org/mailing-lists.html this list is not really moderated and I have *not* spammed you. Just wondering... Thanks, Krista -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- This message is for the named person's use only. This communication is for informational purposes only and has been obtained from sources believed to be reliable, but it is not necessarily complete and its accuracy cannot be guaranteed. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. Moreover, this material should not be construed to contain any recommendation regarding, or opinion concerning, any security. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Securities products and services provided to Canadian investors are offered by ITG Canada Corp. (member CIPF and IIROC - Investment Industry Regulatory Organization of Canada), an affiliate of Investment Technology Group, Inc. Investment research products and services are produced and offered by ITG Investment Research, Inc. and not ITG Inc. (a FINRA member firm and SIPC member). ITG Inc. and/or its affiliates reserves the right to monitor and archive all electronic communications through its network. ITG Inc. Member FINRA, SIPC -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Re: Can you hear me now?
On Wed, Nov 3, 2010 at 14:54, Andersen, Krista wrote: > Hi, > > I tried posting a question to this users list last night and I still don't > see it here (nor any responses). Am I being blocked? Am I being too > impatient? Will I simply not see my own posts until someone replies? Your own posts are not sent back to you. Your post did appear on the list; there are several list archives online you can use to verify this. Because this is a free, strictly volunteer, wide-open mailing list, you are not guaranteed to get answers to your questions - or any response at all, for that matter. That said, the community usually does a good job of tackling questions, assuming they're relevant, understandable, and well-written. Another thing that would help tremendously is to eliminate the miles-long disclaimer on your emails, or use another account which does not tack it on automatically. The validity/enforceability of these disclaimers is dubious at best to begin with, and when posted to public-access mailing lists which are archived and trivially searched via Google, cannot have posts deleted from them, and are completely unrelated to your company's line of business, are completely pointless. > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > This message is for the named person's use only. This communication is for > informational purposes only and has been obtained from sources believed to > be reliable, but it is not necessarily complete and its accuracy cannot be > guaranteed. It is not intended as an offer or solicitation for the purchase > or sale of any financial instrument or as an official confirmation of any > transaction. Moreover, this material should not be construed to contain any > recommendation regarding, or opinion concerning, any security. It may > contain confidential, proprietary or legally privileged information. No > confidentiality or privilege is waived or lost by any mistransmission. If > you receive this message in error, please immediately delete it and all > copies of it from your system, destroy any hard copies of it and notify the > sender. You must not, directly or indirectly, use, disclose, distribute, > print, or copy any part of this message if you are not the intended > recipient. Any views expressed in this message are those of the individual > sender, except where the message states otherwise and the sender is > authorized to state them to be the views of any such entity. > > Securities products and services provided to Canadian investors are offered > by ITG Canada Corp. (member CIPF and IIROC - Investment Industry Regulatory > Organization of Canada), an affiliate of Investment > Technology Group, Inc. > > Investment research products and services are produced and offered by > ITG Investment Research, Inc. and not ITG Inc. (a FINRA member firm and > SIPC member). > > ITG Inc. and/or its affiliates reserves the right to monitor and archive > all electronic communications through its network. > > ITG Inc. Member FINRA, SIPC > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Re: Can you hear me now?
Andy Levy wrote on Wed, Nov 03, 2010 at 15:04:29 -0400: > On Wed, Nov 3, 2010 at 14:54, Andersen, Krista > wrote: > > Hi, > > > > I tried posting a question to this users list last night and I still don't > > see it here (nor any responses). Am I being blocked? Am I being too > > impatient? Will I simply not see my own posts until someone replies? > > Your own posts are not sent back to you. Your post did appear on the > list; there are several list archives online you can use to verify > this. > > Because this is a free, strictly volunteer, wide-open mailing list, > you are not guaranteed to get answers to your questions - or any > response at all, for that matter. That said, the community usually > does a good job of tackling questions, assuming they're relevant, > understandable, and well-written. > In this case, my impression is that (1) the question belongs more on the httpd mailing lists than on the subversion mailing lists; (2) the OP (Krista) can probably answer most of them by herself. (file(1), manpages and the excellent httpd docs are your friends; have you consulted them?) > Another thing that would help tremendously is to eliminate the > miles-long disclaimer on your emails, or use another account which > does not tack it on automatically. The validity/enforceability of > these disclaimers is dubious at best to begin with, and when posted to > public-access mailing lists which are archived and trivially searched > via Google, cannot have posts deleted from them, and are completely > unrelated to your company's line of business, are completely > pointless.
one's own posts Re: Can you hear me now?
Daniel Shahaf wrote on Wed, Nov 03, 2010 at 21:17:09 +0200: > Andy Levy wrote on Wed, Nov 03, 2010 at 15:04:29 -0400: > > On Wed, Nov 3, 2010 at 14:54, Andersen, Krista > > wrote: > > > I tried posting a question to this users list last night and > > > I still don't see it here (nor any responses). Am I being > > > blocked? Am I being too impatient? Will I simply not see my own > > > posts until someone replies? > > > > Your own posts are not sent back to you. Are you sure? I certainly get all my own posts via the list.
Re: one's own posts Re: Can you hear me now?
On Wed, Nov 03, 2010 at 09:20:32PM +0200, Daniel Shahaf wrote: > Daniel Shahaf wrote on Wed, Nov 03, 2010 at 21:17:09 +0200: > > Andy Levy wrote on Wed, Nov 03, 2010 at 15:04:29 -0400: > > > On Wed, Nov 3, 2010 at 14:54, Andersen, Krista > > > wrote: > > > > I tried posting a question to this users list last night and > > > > I still don't see it here (nor any responses). Am I being > > > > blocked? Am I being too impatient? Will I simply not see my own > > > > posts until someone replies? > > > > > > Your own posts are not sent back to you. > > Are you sure? I certainly get all my own posts via the list. Andy is using gmail, which hides a user's own posts to mailing lists.
Re: svn forgets authentication password
On Wed, Nov 3, 2010 at 6:26 AM, David Aldrich wrote: > Hi > > I am running svn command line client 1.6.13 on Linux. Recently (possibly > since upgrading from 1.6.6 to 1.6.13) I have found that whenever I run: > > svn up > > I am prompted for my password. I then choose to save it (unencrypted) but > next time around I am prompted for it again. > > Any idea why this might be please? Hard to tell. Did you compile it yourself, or are you using your distribution's Linux? And have you looked in .subversion for the authorization file with your password stored in it? Mind you, I provoundly loathe this feature. It puts your passwords in clear text in your $HOME/.subversion directory, and is one of the reasons I so strongly espouse svn+ssh access, which typically relies on SSH keys.
Provider encountered an error while streaming a REPORT response.
I am seeing the above error with some frequency, generally producing the following three messages in the logs. [Wed Nov 03 17:11:16 2010] [error] [client 10.1.3.105] Provider encountered an error while streaming a REPORT response. [500, #0] [Wed Nov 03 17:11:16 2010] [error] [client 10.1.3.105] A failure occurred while driving the update report editor [500, #103] [Wed Nov 03 17:11:16 2010] [error] [client 10.1.3.105] Error writing base64 data: Software caused connection abort [500, #103] I see this from a variety of clients (svn 1.4 through svn 1.6) on a variety of OSs (XP, Win7, various linuxes). If it's any clue, it seems most frequent from svnkit clients running on guest OSs on a vmware ESXi host, but it is not restricted to that configuration. I've seen threads pointing to this faq: http://subversion.apache.org/faq.html#tiger-apr-0.9.6, but I am running a much newer version of apr. Any ideas? Thanks, Kylo
Re: Windows client and SASL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 02 Nov 2010 15:31:03 -0400, I said: > TortoiseSVN has no problem operating on this repository, so > either there's a bug in the binary, or, more likely, I haven't > configured something in the command-line environment. Nope, there's a problem with the binary. I downloaded the Slik binary and it works fine. I have also left a message on alagazam.net to this effect. JAB - -- John Alan Belli jabe...@pobox.com http:// coming soon (_...@___#PGP DH/DSS Key ID: 0x9F9A5233 RSA Key ID: 0xFD7399CD U/~ O- Available by finger and on various keyservers -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) - WinPT 1.4.2 Charset: UTF-8 iEYEARECAAYFAkzSL/UACgkQ2IsOhZ+aUjNY8gCg9NJ2svx5kE5IROJVOpicQphK s8YAoLBdhwBgq604CNUBKl3XK/xmyjl5 =MnlA -END PGP SIGNATURE-
