Re: Feature Req: sorthand urls for branches/tags in CLI
On 28.08.2013 05:47, Daniel Shahaf wrote: Branko Čibej wrote on Sun, Aug 25, 2013 at 15:39:29 +0200: On 25.08.2013 15:03, Daniel Shahaf wrote: 'svn mergeinfo' walks the tree upwards. As to listing branches by walking the tree downwards, if you consider 'svn pg -R svn:branch ^/branches', and let N = number of branches and M = number of files per branch, it would do O(NM) work to compute an O(N)-sized answer. That's assuming the server doesn't know about the property. But it has to know in order to implement the branching restrictions I mentioned. You didn't specify whether those restrictions were to be implemented in the client or server. I thought it's obvious that the server has to implement the restrictions, otherwise an older client can mess up your branch metadata. The same is true of the original proposal. Without explicit server support, it's even easier to get the branch property out of sync. Why don't you do a similar cost analysis on the original proposal, taking into account the problems I pointed out? The cost of the original proposal is O(L) dirents-list retrievals where L is the number of patterns in the property (assuming that globs don't recurse, i.e., no **), and in particular is independent of M. And, by the way, I think you mentioned just one problem: the fact that the branch-roots structure is defined in a place other than the branch roots and as such may get out of date. Were there any others? That is the root cause of all the others I mentioned. And by the way, your analysis depends on the assumption that there is exactly one such property in the repository (or project subtree if you want to call it that), and that you never have nested branches, etc. A bit naive in my opinion. Anyway, this thread has gone far beyond the mandate of the users@ list. We should discuss the features on dev@ without the hand-waving. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Feature Req: sorthand urls for branches/tags in CLI
On 27.08.2013 22:51, Kishalmi László wrote: Well as subversion has no branches. Sorry but I have to disagree. Subversion had no /copies/ that are not branches. As far as node history and merging is concerned, /every/ copy is a branch. Saying that Subversion has no branches is incorrect, and making assumptions from that statement will lead to wrong conclusions. Do not confuse the concept of a branch with the concept of a separate namespace for branch names. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Feature Req: sorthand urls for branches/tags in CLI
On 08/28/2013 05:51 AM, Daniel Shahaf wrote: Les Mikesell wrote on Fri, Aug 23, 2013 at 16:07:17 -0500: On Thu, Aug 22, 2013 at 4:15 PM, Laszlo Kishalmi lkisha...@ovi.com wrote: I'd propose a -b [--branch] option or extend the meaning of ^ sign for those commands which can work with URL-s. Extending ˇ would mean that when used as ^/ it means repository root and using it as ^[branch] then it would refer to a branch. How would it work: Let's imagine the following repository layout: /project1/trunk /project1/trunk/dir1/dir2/dir3/fileA /project1/branches/branchA /project1/branches/branchA/dir1/dir2/dir3/fileA /project1/branches/branchB /project1/branches/branchB/dir1/dir2/dir3/fileA /project1/tags/tag1 /project1/tags/tag2 So how do you see this working where your branches have their own sub-levels: /project1/branches/release/branchA /project1/branches/qa/branchA /project1/branches/dev/branchA Who gets to use the shorthand? ^/project1/branches/(qa|dev|release) would be shortened to ^qa/ ^dev/ ^release/. (Or you could try to define something along the lines of '^/.../branches/(qa|dev|release)/([^/+]) \1-\2', but I'm not sure of the details right now) Well in that case a meaningful shorthand would be to use ^qa/branchA, ^dev/branchA and ^release/branchA I think it could be solved by any matcher either using prefix or rexexp, or some simplified regexp one.
Re: Feature Req: sorthand urls for branches/tags in CLI
On 08/23/2013 04:37 PM, Branko Čibej wrote: On 23.08.2013 16:06, Andrew Reedick wrote: -Original Message- From: Laszlo Kishalmi [mailto:lkisha...@ovi.com] Sent: Thursday, August 22, 2013 5:15 PM To: users@subversion.apache.org Subject: Feature Req: sorthand urls for branches/tags in CLI Implementation ideas: We put a specific property on project1 folder let's call it svn:branches for now. Here we could describe the layout of branches and tags for that part of repository. E.g.: a) Using prefixes: / /branches/ /tags/ b) Using some custom mapping/lists: trunk branches/* tags/* c) Using regexp captures: (trunk) branches/(\w+) tags/(\w+) Having this info, the path where this property is set, the name of the branch and the current path relative to wc root it is possible to construct a repository URL to be used. As far as I currently see there would be no change required on server side. Subversion doesn't have branches. I'd rather see branches as first class objects before we hack out a -b option. It's still an interesting idea, though. What happens when the svn:branches property gets merged or copied? It's an edge case, but it could cause an amusing amount of chaos if svn:branches gets copied around or merged unexpectedly. What is the behavior when you are in an externals? Do you respect the svn:branches in the externals, or do you work from the local repo's svn:branches, or neither? Overall, I'm not sure it would save a significant amount of typing. If you have a standard trunk/branches/tags repo structure, then you're not saving a lot by using -b foo in place of ^/branches/foo. Having to set 'svn:branches' for repos with non-standard trunk/branches/tags trees is a bit inconvenient and would discourage use. Actually I find the idea of having a single propery to define project layout totally wrong. What if, at a later date, you change the project structure? Who is responsible for updating the property? How do you keep it in sync with reality? How do you detect that it's out of sync? Those are just a few considerations that have to be addressed, and frankly I don't think there's any sane way of addressing them. This is like the svn:externals mess all over again. Well as subversion has no branches. My idea was just make URL references shorter with just some thought on what if branches were (maybe first class) citizens. So the chosen naming of potions and property was misleading. How these would look like: 1. Ditch -b (--branch) form the original proposal and rename svn:branches as svn:url-search-roots (or somethin similar/better). Using ^[name] for URL would just attempt to match an URL in some (later defined) ways. As of error handling: svn:externals: If there is an easy way to determine if the user is sitting in a directory which belongs to svn:externals we just inform the user that this is not supported. Name collisions: Just say the user that the name is ambiguous ^/ addressing still can be used. Syncing issues: Sync the content of the property shall be done manually. If the team has arranged something and the (later defined) matcher is not completely dumb, then it would be a rare thing. Otherwise the user become unlucky just say that to the user and ^/ addressing still can be used. Branching/Copying: As this property would be used at project level and inherited from there. Regarding normal use cases this shall shall be no issue. However I admit that if someone uses this property on lower levels overriding the inherited one, then it could cause nasty things. In order to prevent that we could just allow only one svn:url-search-roots definition (inherited or not) per every path on the repository. Merge/Conflicts: On normal use cases this shall not happen. Otherwise just treat the property as any other. The user might get unlucky again ^/ addressing still can be used. 2. Start to think how can branches be (first class) citizens in Subversion. ^[branch] could be user there as well. It would be much safer IMO if the root of each branch were identified by a property instead. For example: we could introduce an svn:branch property that can be set only on directories. The presence of such a property tells the client and server that the directory is a branch and should be treated specially. The property could not be manipulated directly via propset or propedit, but only through branch-specific commands; for example: * svn mkdir --branch Creates a new directory with the svn:branch property set, with an empty value Example: svn mkdir --branch http://host/repo/trunk *
Re: Feature Req: sorthand urls for branches/tags in CLI
Branko Čibej wrote on Sun, Aug 25, 2013 at 15:39:29 +0200: On 25.08.2013 15:03, Daniel Shahaf wrote: 'svn mergeinfo' walks the tree upwards. As to listing branches by walking the tree downwards, if you consider 'svn pg -R svn:branch ^/branches', and let N = number of branches and M = number of files per branch, it would do O(NM) work to compute an O(N)-sized answer. That's assuming the server doesn't know about the property. But it has to know in order to implement the branching restrictions I mentioned. You didn't specify whether those restrictions were to be implemented in the client or server. Why don't you do a similar cost analysis on the original proposal, taking into account the problems I pointed out? The cost of the original proposal is O(L) dirents-list retrievals where L is the number of patterns in the property (assuming that globs don't recurse, i.e., no **), and in particular is independent of M. And, by the way, I think you mentioned just one problem: the fact that the branch-roots structure is defined in a place other than the branch roots and as such may get out of date. Were there any others?
Re: Feature Req: sorthand urls for branches/tags in CLI
Les Mikesell wrote on Fri, Aug 23, 2013 at 16:07:17 -0500: On Thu, Aug 22, 2013 at 4:15 PM, Laszlo Kishalmi lkisha...@ovi.com wrote: I'd propose a -b [--branch] option or extend the meaning of ^ sign for those commands which can work with URL-s. Extending ˇ would mean that when used as ^/ it means repository root and using it as ^[branch] then it would refer to a branch. How would it work: Let's imagine the following repository layout: /project1/trunk /project1/trunk/dir1/dir2/dir3/fileA /project1/branches/branchA /project1/branches/branchA/dir1/dir2/dir3/fileA /project1/branches/branchB /project1/branches/branchB/dir1/dir2/dir3/fileA /project1/tags/tag1 /project1/tags/tag2 So how do you see this working where your branches have their own sub-levels: /project1/branches/release/branchA /project1/branches/qa/branchA /project1/branches/dev/branchA Who gets to use the shorthand? ^/project1/branches/(qa|dev|release) would be shortened to ^qa/ ^dev/ ^release/. (Or you could try to define something along the lines of '^/.../branches/(qa|dev|release)/([^/+]) \1-\2', but I'm not sure of the details right now)
Re: Feature Req: sorthand urls for branches/tags in CLI
'svn mergeinfo' walks the tree upwards. As to listing branches by walking the tree downwards, if you consider 'svn pg -R svn:branch ^/branches', and let N = number of branches and M = number of files per branch, it would do O(NM) work to compute an O(N)-sized answer. Branko Čibej wrote on Fri, Aug 23, 2013 at 22:55:03 +0200: On 23.08.2013 21:34, Daniel Shahaf wrote: Branko Čibej wrote on Fri, Aug 23, 2013 at 16:37:47 +0200: * svn mkdir --branch Creates a new directory with the svn:branch property set, with an empty value Example: svn mkdir --branch http://host/repo/trunk 'svn list-branches' would work how? About the same as svn mergeinfo? Or how about a variant on svn status that also looks for that prperty? Frankly, I find this problem infinitesimally small compared to the ones I mentioned in connection with the proposal given in this thread. Indexing based on the presence and/or value of a property is a somewhat orthogonal feature, IMO, but there's been a lot of interest about that as well (e.g., what did user X commit? sure, you can filter 'svn log' but that's kinda slow). If/when it appears, svn list-branches could use it. Until it does, we already more than one command that crawls the whole working copy or repository tree. This one is no different. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Feature Req: sorthand urls for branches/tags in CLI
On Fri, Aug 23, 2013 at 10:55:03PM +0200, Branko Čibej wrote: On 23.08.2013 21:34, Daniel Shahaf wrote: 'svn list-branches' would work how? About the same as svn mergeinfo? Or how about a variant on svn status that also looks for that prperty? Frankly, I find this problem infinitesimally small compared to the ones I mentioned in connection with the proposal given in this thread. Indexing based on the presence and/or value of a property is a somewhat orthogonal feature, IMO, but there's been a lot of interest about that as well (e.g., what did user X commit? sure, you can filter 'svn log' but that's kinda slow). If/when it appears, svn list-branches could use it. Until it does, we already more than one command that crawls the whole working copy or repository tree. This one is no different. Perhaps it would be worthwhile to have extended ops be implemented by a helper binary for such extended purposes (svnstat? svnanalyze?). That way one would not bloat the usual hotpath workhorse binary with such... shenanigans :) (both in performance terms and in usability terms - usage text length...) But that decision probably depends on the total number of conceivable extended ops. If there's only few high-level op names which do all the work and options internally, then one could keep them provided by svn, else... But keeping them in main binary might still influence overall performance - unless implementation data of commands (as possibly opposed to registration data of commands!) is being provided on-demand only anyway, via shared library dlopen references. OTOH you could argue that the total amount of SCM sub commands will ultimately remain limited, thus it's better to keep them aggregated to main binary and do maximum optimization of that case instead (dlopen etc.). E.g. git (Jehovah! ;) seems to be doing it that way, and with external git_load_dirs binary being analogous to svn_load_dirs binary to boot. Apologies for the long rambling - I had expected it to remain shorter, but then with all the details added... Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you.
RE: Feature Req: sorthand urls for branches/tags in CLI
-Original Message- From: Laszlo Kishalmi [mailto:lkisha...@ovi.com] Sent: Thursday, August 22, 2013 5:15 PM To: users@subversion.apache.org Subject: Feature Req: sorthand urls for branches/tags in CLI Implementation ideas: We put a specific property on project1 folder let's call it svn:branches for now. Here we could describe the layout of branches and tags for that part of repository. E.g.: a) Using prefixes: / /branches/ /tags/ b) Using some custom mapping/lists: trunk branches/* tags/* c) Using regexp captures: (trunk) branches/(\w+) tags/(\w+) Having this info, the path where this property is set, the name of the branch and the current path relative to wc root it is possible to construct a repository URL to be used. As far as I currently see there would be no change required on server side. Subversion doesn't have branches. I'd rather see branches as first class objects before we hack out a -b option. It's still an interesting idea, though. What happens when the svn:branches property gets merged or copied? It's an edge case, but it could cause an amusing amount of chaos if svn:branches gets copied around or merged unexpectedly. What is the behavior when you are in an externals? Do you respect the svn:branches in the externals, or do you work from the local repo's svn:branches, or neither? Overall, I'm not sure it would save a significant amount of typing. If you have a standard trunk/branches/tags repo structure, then you're not saving a lot by using -b foo in place of ^/branches/foo. Having to set 'svn:branches' for repos with non-standard trunk/branches/tags trees is a bit inconvenient and would discourage use.
Re: Feature Req: sorthand urls for branches/tags in CLI
On 23.08.2013 16:06, Andrew Reedick wrote: -Original Message- From: Laszlo Kishalmi [mailto:lkisha...@ovi.com] Sent: Thursday, August 22, 2013 5:15 PM To: users@subversion.apache.org Subject: Feature Req: sorthand urls for branches/tags in CLI Implementation ideas: We put a specific property on project1 folder let's call it svn:branches for now. Here we could describe the layout of branches and tags for that part of repository. E.g.: a) Using prefixes: / /branches/ /tags/ b) Using some custom mapping/lists: trunk branches/* tags/* c) Using regexp captures: (trunk) branches/(\w+) tags/(\w+) Having this info, the path where this property is set, the name of the branch and the current path relative to wc root it is possible to construct a repository URL to be used. As far as I currently see there would be no change required on server side. Subversion doesn't have branches. I'd rather see branches as first class objects before we hack out a -b option. It's still an interesting idea, though. What happens when the svn:branches property gets merged or copied? It's an edge case, but it could cause an amusing amount of chaos if svn:branches gets copied around or merged unexpectedly. What is the behavior when you are in an externals? Do you respect the svn:branches in the externals, or do you work from the local repo's svn:branches, or neither? Overall, I'm not sure it would save a significant amount of typing. If you have a standard trunk/branches/tags repo structure, then you're not saving a lot by using -b foo in place of ^/branches/foo. Having to set 'svn:branches' for repos with non-standard trunk/branches/tags trees is a bit inconvenient and would discourage use. Actually I find the idea of having a single propery to define project layout totally wrong. What if, at a later date, you change the project structure? Who is responsible for updating the property? How do you keep it in sync with reality? How do you detect that it's out of sync? Those are just a few considerations that have to be addressed, and frankly I don't think there's any sane way of addressing them. This is like the svn:externals mess all over again. It would be much safer IMO if the root of each branch were identified by a property instead. For example: we could introduce an svn:branch property that can be set only on directories. The presence of such a property tells the client and server that the directory is a branch and should be treated specially. The property could not be manipulated directly via propset or propedit, but only through branch-specific commands; for example: * svn mkdir --branch Creates a new directory with the svn:branch property set, with an empty value Example: svn mkdir --branch http://host/repo/trunk * svn copy If the source is a branch, the target also becomes a branch. The value of the target's svn:branch property is the path@revision of the source (thus, the client and server can easily recognize related branches and branch points). Using property inheritance, client and server can enforce constraints on allowed branching (e.g., forbid branching into a copy of the source branch) * svn move Can implement restrictions upon where branches can be moved to, similar to svn copy * svn diff, svn merge, svn switch These commands could make use of a (new) shorthand syntax to identify branches, based on their (base)name and the presence of the svn:branch property. We actually had quite a fight^Winteresting discussion about this at the Berlin hackathon this year. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Feature Req: sorthand urls for branches/tags in CLI
Branko Čibej wrote on Fri, Aug 23, 2013 at 16:37:47 +0200: * svn mkdir --branch Creates a new directory with the svn:branch property set, with an empty value Example: svn mkdir --branch http://host/repo/trunk 'svn list-branches' would work how?
Re: Feature Req: sorthand urls for branches/tags in CLI
On Thu, Aug 22, 2013 at 4:15 PM, Laszlo Kishalmi lkisha...@ovi.com wrote: I'd propose a -b [--branch] option or extend the meaning of ^ sign for those commands which can work with URL-s. Extending ˇ would mean that when used as ^/ it means repository root and using it as ^[branch] then it would refer to a branch. How would it work: Let's imagine the following repository layout: /project1/trunk /project1/trunk/dir1/dir2/dir3/fileA /project1/branches/branchA /project1/branches/branchA/dir1/dir2/dir3/fileA /project1/branches/branchB /project1/branches/branchB/dir1/dir2/dir3/fileA /project1/tags/tag1 /project1/tags/tag2 So how do you see this working where your branches have their own sub-levels: /project1/branches/release/branchA /project1/branches/qa/branchA /project1/branches/dev/branchA Who gets to use the shorthand? -- Les Mikesell lesmikes...@gmail.com
Re: Feature Req: sorthand urls for branches/tags in CLI
Laszlo Kishalmi wrote on Thu, Aug 22, 2013 at 23:15:04 +0200: Implementation ideas: We put a specific property on project1 folder let's call it svn:branches for now. Here we could describe the layout of branches and tags for that part of repository. E.g.: a) Using prefixes: / /branches/ /tags/ b) Using some custom mapping/lists: trunk branches/* tags/* c) Using regexp captures: (trunk) branches/(\w+) tags/(\w+) Having this info, the path where this property is set, the name of the branch and the current path relative to wc root it is possible to construct a repository URL to be used. How do you handle collisions --- e.g., branches/foo and tags/foo ? As far as I currently see there would be no change required on server side. Yes. There's the svn:externals parser to consider but it's client-side too.
Re: Feature Req: sorthand urls for branches/tags in CLI
On 8/22/13 2:15 PM, Laszlo Kishalmi wrote: I'd propose a -b [--branch] option or extend the meaning of ^ sign for those commands which can work with URL-s. Extending ˇ would mean that when used as ^/ it means repository root and using it as ^[branch] then it would refer to a branch. How would it work: Let's imagine the following repository layout: /project1/trunk /project1/trunk/dir1/dir2/dir3/fileA /project1/branches/branchA /project1/branches/branchA/dir1/dir2/dir3/fileA /project1/branches/branchB /project1/branches/branchB/dir1/dir2/dir3/fileA /project1/tags/tag1 /project1/tags/tag2 Use Case 1: We are in the WC root of checked out trunk and would like merge branchA back. svn merge -b branchA svn merge ^branchA I'm not sure how I see that this is so much better than just doing: svn merge ^/project1/branches/branchA I type these sort of things routinely with our own Subversion repo as: ^/subversion/trunk and ^/subversion/branches/1.8.x on a regular basis. If you want to make quickly aliases why not just use the variable support of your shell? E.G. with bash: branchA=^/project1/branches/branchA svn merge $branchA Or heck you can make it even shorter to type: bA=^/project1/branches/branchA svn merge $bA I used to do shell variables a lot before ^/ was added. That's back when we were hosted on subversion.tigris.org and we didn't have other projects in our repo and our trunk was a child of the root. With ^/ even with the subversion parent above our repo I just don't find myself using the variables. I'm sure you can probably even get your shell to be fancy and figure out what project you're working in and apply the proper root (you have access to this with svn info). Additionally I'm concerned that this just confuses the meaning for users of how ^/ works. I can already see the user complaints that Subversion merged the wrong thing for them because they forget -b. Let's just say that at this point I'm skeptical of the need for this.
