Re: Seg fault when committing 'forks' with svn 1.8.1 client
Stephane Odul writes: > I have a project that I need to fork (in the same repo): > $ svn cp foo bar > $ svn rm bar/trunk/some_dir > $ svn rm bar/trunk/some_file > $ emacs bart/trunk/other_files > $ svn ci > Segmentation fault: 11 Is that issue 4400? http://subversion.tigris.org/issues/show_bug.cgi?id=4400 If so it should be fixed in 1.8.3. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: assertion failed (SV_IS_VALID_REVNUM(*youngest))
On Wed, Aug 21, 2013 at 09:44:00AM -0600, Scott Chantry wrote: > TortoiseSVN 1.8.1 windows x64. I opened up repo browser and after a long > wait, this error popped up. I can't do anything with tortoisesvn1.8.1 I believe this will be fixed with Subversion 1.8.3 (ETA end of next week). Please let us know if that isn't the case. > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the time to report this on the Subversion mailing list > with as much information as possible about what > you were trying to do. > But please first search the mailing list archives for the error message > to avoid reporting the same problem repeatedly. > You can find the mailing list archives at > http://subversion.apache.org/mailing-lists.html > > Subversion reported the following > (you can copy the content of this dialog > to the clipboard using Ctrl-C): > > In file > > 'D:\Development\SVN\Releases\TortoiseSVN-1.8.1\ext\subversion\subversion\libsvn_ra_serf\options.c' > line 446: assertion failed (SVN_IS_VALID_REVNUM(*youngest)) > --- > OK > ---
Re: using "svn merge", "svn diff", and "svn patch"
On Thu, Aug 22, 2013 at 09:40:08AM -0400, James Hanley wrote: > So other then tar-ing up the WC, there is no way to reproduce local changes > like this on another system? I know the example given is fairly simple, > but it could be very useful. If the changeset you want to transfer between working copies cannot be fully represented by 'svn diff'/'svn patch' (i.e. it contains copies, replacements, or svn:mergeinfo changes), I would recommend to commit your changeset to a new branch and checkout/merge that branch elsewhere. The changes will appear in repository history but they don't need to affect anything of value. Say you did: svn checkout TRUNK_URL first-wc cd first-wc make changes in first-wc Now you could do this to create a new branch: svn copy ^/trunk ^/branches/my-new-branch svn switch ^/branches/my-new-branch svn commit Or even just: svn copy . ^/branches/my-new-branch The other side can now checkout the branch: svn checkout ^/branches/my-new-branch Or switch an existing trunk working copy to the branch: cd other-trunk-wc svn switch ^/branches/my-new-branch Or merge the branch into an existing trunk working copy: cd other-trunk-wc svn merge ^/branches/my-new-branch (The above assumes a Subversion 1.8 client. Older clients need the --reintegrate option).
New To SVN
Hello, I am able to create the repository using svnadmin create --fs-type fsfs http://demo/~deepak/svn But the import of a directory is giving error -bash-4.2$ svn import -m "New import" /home/deepak/keyword_spotter http://localhost/~deepak/svn svn: Repository moved permanently to 'http://demo/~deepak/svn/'; please relocate Regards Deepak Bhatia Software Consultant Voxomos Systems Pvt. Limited Mobile: 91 9811196957 C56A/27, Sector 62, NOIDA (NCR), UP, India Skype: toreachdeepak
Re: New To SVN
On Fri, Aug 23, 2013 at 06:07:42PM +0530, Deepak Bhatia wrote: > Hello, > > I am able to create the repository using > > svnadmin create --fs-type fsfs http://demo/~deepak/svn 'svnadmin create' requires a local path to a directory that does not yet exist. It is supposed to be run on the SVN server itself. It cannot work over HTTP. You need command line access to the server. You've created a repository on your client computer in a directory which has a name that looks like a URL. Please see here for details: http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html > But the import of a directory is giving error > > -bash-4.2$ svn import -m "New import" /home/deepak/keyword_spotter > http://localhost/~deepak/svn > svn: Repository moved permanently to 'http://demo/~deepak/svn/'; please > relocate > > Regards > > Deepak Bhatia > Software Consultant > Voxomos Systems Pvt. Limited > Mobile: 91 9811196957 > C56A/27, Sector 62, NOIDA (NCR), UP, India > Skype: toreachdeepak
Re: New To SVN
Hello, Ok I created a repository by giving the absolute path to the directory. svnadmin create --fs-type fsfs /home/deepak/public_html/svn2 Then importing a directory is giving the error -bash-4.2$ svn import -m "New Import" . http://demo.voxomos.com/~deepak/svn2 svn: Repository moved permanently to 'http://demo.voxomos.com/~deepak/svn2/'; please relocate Deepak Bhatia Software Consultant Voxomos Systems Pvt. Limited Mobile: 91 9811196957 C56A/27, Sector 62, NOIDA (NCR), UP, India Skype: toreachdeepak On Fri, Aug 23, 2013 at 6:17 PM, Stefan Sperling wrote: > On Fri, Aug 23, 2013 at 06:07:42PM +0530, Deepak Bhatia wrote: > > Hello, > > > > I am able to create the repository using > > > > svnadmin create --fs-type fsfs http://demo/~deepak/svn > > 'svnadmin create' requires a local path to a directory that > does not yet exist. It is supposed to be run on the SVN server itself. > It cannot work over HTTP. You need command line access to the server. > > You've created a repository on your client computer in a directory > which has a name that looks like a URL. > > Please see here for details: > http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html > > > But the import of a directory is giving error > > > > -bash-4.2$ svn import -m "New import" /home/deepak/keyword_spotter > > http://localhost/~deepak/svn > > svn: Repository moved permanently to 'http://demo/~deepak/svn/'; > please > > relocate > > > > Regards > > > > Deepak Bhatia > > Software Consultant > > Voxomos Systems Pvt. Limited > > Mobile: 91 9811196957 > > C56A/27, Sector 62, NOIDA (NCR), UP, India > > Skype: toreachdeepak >
svn merge
How reliable is svn merge? What changes are that it fails with success(instead of throwing a conflict it does a wrong merge)?
Re: New To SVN
On Fri, Aug 23, 2013 at 06:38:42PM +0530, Deepak Bhatia wrote: > Hello, > > Ok I created a repository by giving the absolute path to the directory. > > svnadmin create --fs-type fsfs /home/deepak/public_html/svn2 > > Then importing a directory is giving the error > > -bash-4.2$ svn import -m "New Import" . http://demo.voxomos.com/~deepak/svn2 > svn: Repository moved permanently to 'http://demo.voxomos.com/~deepak/svn2/'; > please relocate How did you configure HTTPD for Subversion exactly? You'll need to add a statement to your httpd configuration that maps a URL such as http://demo.voxomos.com/svn/ to the on-disk path /home/deepak/public_html/svn2. Something like this: ... SVNPath /home/deepak/public_html/svn2 ... Then use the URL http://demo.voxomos.com/svn/ to access the repositories. More details at http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html
Re: Feature Req: sorthand urls for branches/tags in CLI
Ben Reser wrote on Thu, Aug 22, 2013 at 22:18:49 -0700: > bA=^/project1/branches/branchA > svn merge $bA That was also the argument against adding ^/, wasn't it? The counter-argument is that "Make URL targets easier to input" is a problem that every user of the cmdline client has (scripts included, btw), so it makes sense to solve it centrally. > 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. I don't like -b. It's a confusing syntax, mixing named and positional arguments (how would it work with 'svn diff --old=URL'?), interferering with the '--' convention, etc. But extending ^/bar to ^foo/bar is something I've long wanted to see, precisely so that URLs other than the repository root may be abbreviated. (Right now ^ must always be followed by /.) I've been thinking of a config file entry, mapping "foo" to expanded value of "^/foo", but an inherited property (so we don't need to figure out "/subversion" from the wc root URL's[1]) is an interesting alternative. A problem with the regexp captures approach is that it doesn't allow shortening the basename, while I would like to, say, shorten "fsfs-improvements" and "invoke-diff-cmd-feature" to "fsfs-imp" and, say, "idc". Perhaps we should extend the syntax to allow making something other than \1 (first capture group) the shortname of a given regexp match? Daniel [1] We can't assume a particular repository layout.
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: Switching
I will try to explain one more time. The files in question are settings files (think config files) and intermediate compilet generated files. The settings files can be recreated at any time. If they are wrong the only thing affected is the development environment. The other files get recreated every time the code is run, plus they never get into production. So they 1) could be recreated any time at will with the versioned code files and 2) they will never be in production anyway. Don't read more than what is stated otherwise you have a chance of being wrong and wasting time. Someone was claiming the files are "important" which I never stated. I didn't even respond to the mail since it was erroneous and irrelevant. The real reason I responded is the force option eliminates the conflict but creates some questions. The documentation says using it will make sure "unversioned obstructiong paths do not cause a failure". Could that also be written as "unversioned obstructiong paths do not cause a conflict"? Or is there some other kind of failure that I do not know about. The problem this fixes displays as "Local unversioned, incoming add upon switch" which is the result of a switch. The revert command fails to bring my working copy back to its unconflicted state. Switching back also fails. The question is can I bring back my working directory from a failed switch (I'm talking undo, not resolve) so I can use the force option or must I always use the force option to be able to switch branches? Have a good weekend JM -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 5:17 PM To: John Maher Cc: Edwin Castro; users@subversion.apache.org Subject: Re: Switching On Thu, Aug 22, 2013 at 1:34 PM, John Maher wrote: > Again Les, you misunderstand. I have no problems with the workspace. It is > exactly the same for everyone, everytime. Please read carefully before you > respond. It has nothing to do with the build. It is user settings, a config > file, ini file, choose your terminology. If you don't understand please ask > for clarification instead of making incorrect assumptions. The contents of the file are irrelevant. The point is that it has to either be versioned so svn can delete it knowing that you can get it back, and then delete the containing directory that is really the issue, or you have to delete it yourself. Pick one. If it really is always the same, I don't see the problem with committing it. If it isn't, and you need to reproduce it, you need to work out a way to do that, or use the multiple-checkout approach to maintain dirty workspaces, realizing that you can't reproduce them reliably. Personally, I don't like things that rely on any unversioned state getting into production releases. That developer will leave or that machine will crash and all the magic is gone - and if you can't do a matching build on a clean machine from a clean checkout, you won't ever know how much magic was involved. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
Edwin Castro wrote: > I think the --force option is dangerous. Try it out but, in my opinion, > you should not use it. Why? Doesn't it perfectly solve the described problem? I had like so many others given up on switch, because cleaning up working copies prior to the switch was annoying busywork, an unnecessary risk (you might delete files that you wished you hadn't) and very easily forgotten, leading to a messed up working copy. But now I'm beginning to rethink that; I just have to remember to use --force with every svn switch. I don't buy the argument about different histories: the pre-existing directory doesn't have a subversion history, so from svn's point of view there is no conflict. What are the real, practical problems that you know of or foresee with svn swich --force? regards, Anders
Re: Switching
On 8/23/13 8:16 AM, Anders J. Munch wrote: > Edwin Castro wrote: >> I think the --force option is dangerous. Try it out but, in my opinion, >> you should not use it. > Why? Doesn't it perfectly solve the described problem? The problem with --force, as the documentation points out, is that it can make things versioned that were previously unversioned. Using a concrete example, a *.sou file that was previously unversioned might become versioned after a switch and then gets committed, accidentally, into your respository. > I had like so many others given up on switch, because cleaning up > working copies prior to the switch was annoying busywork, an > unnecessary risk (you might delete files that you wished you hadn't) > and very easily forgotten, leading to a messed up working copy. But > now I'm beginning to rethink that; I just have to remember to use > --force with every svn switch. > > I don't buy the argument about different histories: the pre-existing > directory doesn't have a subversion history, so from svn's point of > view there is no conflict. What are the real, practical problems that > you know of or foresee with svn swich --force? > When objects do not have history, then subversion is in the position to try to decide what to do with content that already exists on the filesystem. It can't make reasonable decisions because there is no base revision to use in the 3-way diff. Ultimately, the proper response is for subversion to say "I can't add the file/directory/what-have-you because there is something blocking my way". It then becomes the user's responsibility to determine what to do. Thinking in the most general sense, one solution for this scenario might work well for one individual but not another. The prescribed solution might not even work reliably every time that one individual sees this scenario. In order for subversion to do the right thing it would need to be psychic. I'm afraid subversion already takes the best possible action which is to require user intervention. -- Edwin G. Castro
Re: Switching
On 8/23/13 7:43 AM, John Maher wrote: > The question is can I bring back my working directory from a failed switch > (I'm talking undo, not resolve) so I can use the force option or must I > always use the force option to be able to switch branches? I think the mailing list has already said the *best* way to use switch is to have a clean working copy (clean out all ignored and unversioned files which is admittedly inconvenient). Some offered the opinion that the best way to use switch was to not use it at all. One way to bring back your working directory from a failed switch is to delete the conflicted directory and then svn update. If your entire working copy is "failed" then you'd need to delete the working copy and checkout again. I suppose you could try switching back to a branch that doesn't contain the directory in question, clean up, and then switch back. Use --force with caution. According to the documentation it can accidentally version previously unversioned files. -- Edwin G. Castro
Re: Switching
On 8/23/13 7:43 AM, John Maher wrote: > The files in question are settings files (think config files) and > intermediate compilet generated files. The settings files can be recreated > at any time. If they are wrong the only thing affected is the development > environment. The other files get recreated every time the code is run, plus > they never get into production. So they 1) could be recreated any time at > will with the versioned code files and 2) they will never be in production > anyway. Don't read more than what is stated otherwise you have a chance of > being wrong and wasting time. When these files get in the way of subversion performing an operation, then the sensible thing to do is to delete them. I think I heard many people voice this opinion on this mailing list. If their contents should be kept around then they should be versioned. That opinion was also voiced by the mailing list. -- Edwin G. Castro
Re: Switching
On Fri, Aug 23, 2013 at 09:24:52AM -0700, Edwin Castro wrote: > I think the mailing list has already said the *best* way to use switch > is to have a clean working copy (clean out all ignored and unversioned > files which is admittedly inconvenient). This won't help right now, but cleaning out such items will be easier in Subversion 1.9: https://blog.elegosoft.com/?q=cleaning-up-svn-cleanup
RE: Switching
Good to know, thank you. -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Friday, August 23, 2013 12:50 PM To: Edwin Castro Cc: users@subversion.apache.org Subject: Re: Switching On Fri, Aug 23, 2013 at 09:24:52AM -0700, Edwin Castro wrote: > I think the mailing list has already said the *best* way to use switch > is to have a clean working copy (clean out all ignored and unversioned > files which is admittedly inconvenient). This won't help right now, but cleaning out such items will be easier in Subversion 1.9: https://blog.elegosoft.com/?q=cleaning-up-svn-cleanup
Re: Switching
On Fri, Aug 23, 2013 at 11:17 AM, Edwin Castro <0ptikgh...@gmx.us> wrote: >>> >> I don't buy the argument about different histories: the pre-existing >> directory doesn't have a subversion history, so from svn's point of >> view there is no conflict. What are the real, practical problems that >> you know of or foresee with svn swich --force? >> > > When objects do not have history, then subversion is in the position to > try to decide what to do with content that already exists on the > filesystem. I can't, off the top of my head, think of a scenario where it would be harmful to replace an unversioned directory with a versioned instance, leaving any unversioned local files that happen to be there alone. Other than maybe the chance that you'd accidentally commit them later, but that is no different than if you had put the local files in after the switch. Am I missing something? Is there a way to --force that without also potentially --force'ing files that conflict to be clobbered? -- Les Mikesell lesmikes...@gmail.com
Re: Switching
On 8/23/13 10:34 AM, Les Mikesell wrote: > I can't, off the top of my head, think of a scenario where it would be > harmful to replace an unversioned directory with a versioned instance, > leaving any unversioned local files that happen to be there alone. Leaving unversioned local files alone in a directory is not the problem. I've personally ran into scenarios where the local directory contained unversioned local files that obstruct a file that will be added by a switch/update/merge/what-have-you. If the local file's content matches the content in the repository, then I think it is safe to simply replace the unversioned local file with the versioned file from the repository. Often, the content has not been the same. It all depends on a lot of factors such as how it became unversioned, what has happened to the file while it was unversioned, etc. Replacing the content of the local file with the content in the repository looses local data. Merging the unversioned content and the versioned content usually result in poor merges (in the best case scenario) because there is no base revision to use in the 3-way merge. I've seen merges like this get committed accidentally and cause havoc. Of course, using the unversioned local content instead of merging the content from the repository could accidentally replace the entire contents of the file and this can accidentally get committed as well. Subversion needs the user's help to figure out what to do and marks these conflicts as tree conflicts.
Re: Switching
On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro <0ptikgh...@gmx.us> wrote: >> I can't, off the top of my head, think of a scenario where it would be >> harmful to replace an unversioned directory with a versioned instance, >> leaving any unversioned local files that happen to be there alone. > > Leaving unversioned local files alone in a directory is not the problem. I think it is the problem we've been discussing. Leaving them means you have to keep the containing directory, which becomes unversioned as you switch away from the branch having it, and then a conflict when you switch back. > I've personally ran into scenarios where the local directory contained > unversioned local files that obstruct a file that will be added by a > switch/update/merge/what-have-you. Don't think that's the case here. These files are supposed to be svn-ignored, so they should not have a copy in the repo. > If the local file's content matches > the content in the repository, then I think it is safe to simply replace > the unversioned local file with the versioned file from the repository. Yes, that would be handy - and harmless - as well. > Often, the content has not been the same. It all depends on a lot of > factors such as how it became unversioned, what has happened to the file > while it was unversioned, etc. Replacing the content of the local file > with the content in the repository looses local data. Agreed, there is no reasonable way to handle this case automatically. But it shouldn't happen as long as the clutter is never committed. It is probably bad practice to default to letting cruft stay across switches since your workspace would end up different than a fresh checkout but it would be handy to have a way to force mostly-harmless operations without overwriting any differing file data. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
> -Original Message- > From: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Friday, August 23, 2013 1:34 PM > To: Edwin Castro > Cc: Subversion > Subject: Re: Switching > > > I can't, off the top of my head, think of a scenario where it would be > harmful to replace an unversioned directory with a versioned instance, > leaving any unversioned local files that happen to be there alone. > Other than maybe the chance that you'd accidentally commit them later, > but that is no different than if you had put the local files in after > the switch. Am I missing something? Is there a way to --force that > without also potentially --force'ing files that conflict to be > clobbered? > Dir permissions and ownership would change to that of the current user and umask and could create a security gap, but that probably falls under "if you're using --force, it's on your head". How are symlinks handled by switch --force? It fails, or does it look at the target file/dir when deciding whether to replace it with a versioned object? How are hardlinks handled by switch --force? Is the hardlinked file removed and replaced with a brand new file? Or does switch --force work directly on the hardlinked file thus updating all the "copies"? On the windows side, would replacing a junction cause problems?
Re: Switching
On Fri, Aug 23, 2013 at 1:33 PM, Andrew Reedick wrote: >> >> I can't, off the top of my head, think of a scenario where it would be >> harmful to replace an unversioned directory with a versioned instance, >> leaving any unversioned local files that happen to be there alone. >> Other than maybe the chance that you'd accidentally commit them later, >> but that is no different than if you had put the local files in after >> the switch. Am I missing something? Is there a way to --force that >> without also potentially --force'ing files that conflict to be >> clobbered? >> > > Dir permissions and ownership would change to that of the current user and > umask and could create a security gap, but that probably falls under "if > you're using --force, it's on your head". > > How are symlinks handled by switch --force? It fails, or does it look at the > target file/dir when deciding whether to replace it with a versioned object? > > How are hardlinks handled by switch --force? Is the hardlinked file removed > and replaced with a brand new file? Or does switch --force work directly on > the hardlinked file thus updating all the "copies"? > > On the windows side, would replacing a junction cause problems? > For this particular case, where the 'unversioned' directory was in fact created by svn and abandoned instead of being deleted during a switch to a branch without it, I don't think any of those scenarios are possible. But, you are right that in the general case svn would have to check for special circumstances and raise conflicts if you have done something weird. -- Les Mikesell lesmikes...@gmail.com
Re: Seg fault when committing 'forks' with svn 1.8.1 client
On Fri Aug 23 01:36:55 2013, Philip Martin wrote: > Stephane Odul writes: > >> I have a project that I need to fork (in the same repo): >> $ svn cp foo bar >> $ svn rm bar/trunk/some_dir >> $ svn rm bar/trunk/some_file >> $ emacs bart/trunk/other_files >> $ svn ci >> Segmentation fault: 11 > > Is that issue 4400? > http://subversion.tigris.org/issues/show_bug.cgi?id=4400 > If so it should be fixed in 1.8.3. It is. I replied last night but apparently only replied to Stephane.
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?
Planning a SVN upgrade
Hi - I am currently planning an upgrade from SVN 1.5 (using svnserve and ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for authNz. We have about 50 repos. I'll be moving from an older Ubuntu 8 install to Centos 6 x64. My thought was I could upgrade the SVN installation in place, bringing the repo up to 1.8 and then dump those repos and bring them online in the new environment. We currently use Eclipse as our IDE and Jenkins as our CI tool with Nexus as the object repo. I was thinking to leave the upgrade of Eclipse client and svnkit to the indiviidual so they can decide what direction to take with their working copies et al. I do not foresee any changes I would need to make to Jenkins or Nexus. Has anyone made a jump this large before? Any comments about my upgrade plan? Thanks!
Re: Planning a SVN upgrade
On Fri, Aug 23, 2013 at 4:09 PM, Maureen Barger wrote: > I am currently planning an upgrade from SVN 1.5 (using svnserve and > ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for > authNz. > We have about 50 repos. I'll be moving from an older Ubuntu 8 install > to Centos 6 x64. > > My thought was I could upgrade the SVN installation in place, bringing > the repo up to 1.8 and then dump those repos and bring them online in > the new environment. > If it were me, I would not upgrade the repositories. SVN 1.8 can just serve the old repositories. I would do the upgrade and only after I was using it for a while would I then consider to start doing a dump/load on the repositories. You could then do them one by one as desired. The main benefit in upgrading the repository is to use less disk space. > We currently use Eclipse as our IDE and Jenkins as our CI tool with > Nexus as the object repo. I was thinking to leave the upgrade of > Eclipse client and svnkit to the indiviidual so they can decide what > direction to take with their working copies et al. Yes, your clients can already be using 1.8 if they want to. There is no need to upgrade the client either before or after the server. Let the clients manage it. Only exception is if there are specific new features you want to implement across the board. If you do a lot of branching and merging, it would be a good idea for the people that do merge to all be using the same version. Likewise, there are other features that might be like this. > I do not foresee > any changes I would need to make to Jenkins or Nexus. > Just the URL to access the repository will change. > > Has anyone made a jump this large before? Any comments about my upgrade > plan? > There is nothing unusual about this. People have jumped from 1.1 to 1.8. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Feature Req: sorthand urls for branches/tags in CLI
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 Thu, Aug 22, 2013 at 4: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 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
how to simply : $svn update ?
I do '$svn status' and get that I am at a certain revision Type 'svn help' for usage. cpu:/dir>svn update At revision 32933. This leads me to believe that I am fully sync'd with the repo since it pulled nothing back. --- I do svn status and see something surprising cpu:/dir>svn status ? src/main ? src/test/java ? src/test/resources/META-INF means the above files are not added and do not exist in the remote repo (but yes they indeed exist there, If I do a fresh checkout, I see these directories there with many files. --- I have not touched this project, and have no idea why it is out of whack. What I want to do is force sync with the repo. When I google on this, I am taken down long tunnels in various caves with so many confusing solutions. In my head, I think I should simply be able to do: $svn --force update or something simple like that. How do I do this? ---
RE: how to simply : $svn update ?
> I do '$svn status' > and get that I am at a certain revision > > Type 'svn help' for usage. > cpu:/dir>svn update > At revision 32933. > > This leads me to believe that I am fully sync'd with the repo since it pulled > nothing back. > > --- I do svn status and see something surprising > > cpu:/dir>svn status > ? src/main > ? src/test/java > ? src/test/resources/META-INF > > means the above files are not added and do not exist in the remote repo (but > yes they indeed exist there, If I do a fresh checkout, I see these directories > there with many files. > > --- > I have not touched this project, and have no idea why it is out of whack. > > What I want to do is force sync with the repo. When I google on this, I am > taken down long tunnels in various caves with so many confusing solutions. > > In my head, I think I should simply be able to do: > $svn --force update > > or something simple like that. > > How do I do this? Try svn cleanup Then check your status. Bob
RE: how to simply : $svn update ?
> From: Jay Vee [mailto:jvsr...@gmail.com] > Sent: Friday, August 23, 2013 5:09 PM > To: users@subversion.apache.org > Subject: how to simply : $svn update ? > > I do '$svn status' > and get that I am at a certain revision > > Type 'svn help' for usage. > cpu:/dir>svn update > At revision 32933. > > This leads me to believe that I am fully sync'd with the repo since it pulled > nothing back. > > --- I do svn status and see something surprising > > cpu:/dir>svn status >? src/main >? src/test/java >? src/test/resources/META-INF > > means the above files are not added and do not exist in the remote repo (but > yes they indeed > exist there, If I do a fresh checkout, I see these directories there with > many files. What's the output of 'svn update'? Is your workspace really pointed to where you think it's pointing? Run 'svn info' to verify the URL and revision numbers.
Re: Seg fault when committing 'forks' with svn 1.8.1 client
Thanks for the quick replies. Looking forward to svn 1.8.3. On Aug 23, 2013, at 11:56 AM, Ben Reser wrote: > On Fri Aug 23 01:36:55 2013, Philip Martin wrote: >> Stephane Odul writes: >> >>> I have a project that I need to fork (in the same repo): >>> $ svn cp foo bar >>> $ svn rm bar/trunk/some_dir >>> $ svn rm bar/trunk/some_file >>> $ emacs bart/trunk/other_files >>> $ svn ci >>> Segmentation fault: 11 >> >> Is that issue 4400? >> http://subversion.tigris.org/issues/show_bug.cgi?id=4400 >> If so it should be fixed in 1.8.3. > > It is. I replied last night but apparently only replied to Stephane.
Re: Switching
On Aug 23, 2013, at 13:31, Les Mikesell wrote: > On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro wrote: > >>> I can't, off the top of my head, think of a scenario where it would be >>> harmful to replace an unversioned directory with a versioned instance, >>> leaving any unversioned local files that happen to be there alone. >> >> Leaving unversioned local files alone in a directory is not the problem. > > I think it is the problem we've been discussing. Leaving them means > you have to keep the containing directory, which becomes unversioned > as you switch away from the branch having it, Correct. > and then a conflict when > you switch back. *This* is the problem we're discussing. *This* is what Subversion should be smart enough to avoid. None of the discussion I've read thus far gives me a convincing explanation for why this should not be possible.
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.
