Re: Error assertion during update
On Thu, Jun 13, 2013 at 3:54 PM, פאנל תוכנה - ניר בר wrote: > Hi, > I encountered this error while updating from windows explorer. > I discovered that someone committed to the repository a folder called "E:" > After removing that folder from the repository the error didn't re-occur > > Nir > > > > > --- > 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.7.12\ext\subversion\subversion\libsvn_wc\update_editor.c' > line 1587: assertion failed (action == svn_wc_conflict_action_edit || > action > == svn_wc_conflict_action_delete || action == > svn_wc_conflict_action_replace) > --- > --- > Hi Nir, Thanks for the report. I believe this crash is specific to TortoiseSVN (so maybe you can also report it on the Tortoise mailinglist [1]). More specifically, with the commandline I also get strange behavior, but not a crash: 1) When I try this with commandline 1.7.9, I get some strange behavior that notifies an "Exists" notification (E), but doesn't really checkout the directory. See below [2]. This is obviously a bug, but it doesn't crash. It seems this is very much like this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3288 (svn crashes when checking out subdirectories with backslashes in their names), which is fixed in 1.8.0, but see below. 2) When I try this with commandline 1.8.0 (to be released in a couple of days), I get a nice error, but the output isn't exactly right. It says: [[[ C:\Temp\svntest18>svn --version -q 1.8.0 C:\Temp\svntest18>svnadmin create repos C:\Temp\svntest18>svn co file:///c:/temp/svntest18/repos wc Checked out revision 0. C:\Temp\svntest18>svn mkdir -mm "file:///c:/temp/svntest18/repos/E:" Committed revision 1. C:\Temp\svntest18>svn up wc Updating 'wc': svn: E155000: '.' is not valid as filename in directory 'C:\Temp\svntest18\wc' ]]] So instead of 'E:' it says '.'. But it's already much better than 1.7. I'll check if I can find out why it doesn't report the correct invalid filename. [1] http://tortoisesvn.net/community.html [2] With 1.7.9 I get the following: [[[ C:\Temp\svntest>svnadmin create repos C:\Temp\svntest>svn co file:///c:/temp/svntest/repos wc Checked out revision 0. C:\Temp\svntest>cd wc C:\Temp\svntest\wc>cd .. C:\Temp\svntest>svn mkdir -mm "file:///c:/temp/svntest/repos/E:" Committed revision 1. C:\Temp\svntest>svn ls file:///c:/temp/svntest/repos E:/ C:\Temp\svntest>svn up wc Updating 'wc': Ewc Updated to revision 1. C:\Temp\svntest>cd wc C:\Temp\svntest\wc>dir Volume in drive C has no label. Volume Serial Number is 00C1-25E4 Directory of C:\Temp\svntest\wc 06/16/2013 08:38 PM . 06/16/2013 08:38 PM .. 0 File(s) 0 bytes 2 Dir(s) 32,266,878,976 bytes free ]]] -- Johan
Re: Error assertion during update
On Sun, Jun 16, 2013 at 9:24 PM, Johan Corveleyn wrote: > On Thu, Jun 13, 2013 at 3:54 PM, פאנל תוכנה - ניר בר > wrote: >> Hi, >> I encountered this error while updating from windows explorer. >> I discovered that someone committed to the repository a folder called "E:" >> After removing that folder from the repository the error didn't re-occur >> >> Nir >> >> >> >> >> --- >> 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.7.12\ext\subversion\subversion\libsvn_wc\update_editor.c' >> line 1587: assertion failed (action == svn_wc_conflict_action_edit || >> action >> == svn_wc_conflict_action_delete || action == >> svn_wc_conflict_action_replace) >> --- >> --- >> > > Hi Nir, > > Thanks for the report. I believe this crash is specific to TortoiseSVN > (so maybe you can also report it on the Tortoise mailinglist [1]). > More specifically, with the commandline I also get strange behavior, > but not a crash: > > 1) When I try this with commandline 1.7.9, I get some strange behavior > that notifies an "Exists" notification (E), but doesn't really > checkout the directory. See below [2]. This is obviously a bug, but it > doesn't crash. It seems this is very much like this issue: > http://subversion.tigris.org/issues/show_bug.cgi?id=3288 (svn crashes > when checking out subdirectories with backslashes in their names), > which is fixed in 1.8.0, but see below. > > 2) When I try this with commandline 1.8.0 (to be released in a couple > of days), I get a nice error, but the output isn't exactly right. It > says: > > [[[ > C:\Temp\svntest18>svn --version -q > 1.8.0 > > C:\Temp\svntest18>svnadmin create repos > > C:\Temp\svntest18>svn co file:///c:/temp/svntest18/repos wc > Checked out revision 0. > > C:\Temp\svntest18>svn mkdir -mm "file:///c:/temp/svntest18/repos/E:" > > Committed revision 1. > > C:\Temp\svntest18>svn up wc > Updating 'wc': > svn: E155000: '.' is not valid as filename in directory 'C:\Temp\svntest18\wc' > ]]] > > So instead of 'E:' it says '.'. But it's already much better than 1.7. > I'll check if I can find out why it doesn't report the correct invalid > filename. For completeness, I filed the 1.8 "imperfect error message" as an issue here: http://subversion.tigris.org/issues/show_bug.cgi?id=4377 (svn reports "'.' is not valid as filename" when updating a dir named 'E:' on Windows) I quite happy myself that 1.8 already gives a reasonable error message (even though it's not perfect). But if anyone else would like to improve this: feel free to give it a go and submit a patch [1]. [1] http://subversion.apache.org/docs/community-guide/general.html#patches Cheers, -- Johan
Re: History in subversion
Thanks, that's a lot to think about, >>> From: Les Mikesell >Taking the history in a copy is what makes svn work and it makes any > copied directory functionally usable as a branch or tag. But after > that it depends on how you actually use it... As consequence, SVN allows to create branches and tags on a part of the software of the repository, starting at a subdirectory and the copy command can then control/limit the scope of the branch/tag.This can be useful. Now, I only see two uses of the command svn+copy - and two only : - Copy the software of the repository - or a part of it - to the branches or tags repositories, - Restoring a removed file or directory element to the HEAD revision. It is difficult for me to imagine a part (file or whole directory tree) copied to another place of the same software. This would be some kind of hardlinks (against SCM principles !). > I don't know what I'm missing here. How is it better than explicit > commit/update/switch operations? What happens if you are disconnected > while making a change? What if you want your working copy to contain > conflicts for a while before you can decide how best to resolve them? What is nice is : you don't load and you don't update, you just see exactly what is in the repository. Of course, you need to be connected - with a (very) good connection to the servers. If connection is lost, CC is reliable enough to avoid repository corruption. If you want to work on your side, you have to create a branch - nothing very new. > How well does it deal with many concurrent changes with after-the-fact > conflict resolution? Nothing very new again, users can always continue their work, but they have to merge at checkin. I think that CC and SVN are very close on this. Just that CC manages individual checkout with reservation, and this can block the work of the team. CC Admin have often to help in order to solve checkouts. I think SVN is better on this point. >>> From: Andreas Krey > As I understand it, when you commit your stuff it also becomes immediately > visible in all other views that look at the same branch. That is a bit > disturbing. Not really, this is like "The 'dirty-trunk' style" described by Les. People write on one same branch, this works for small team (5 max). Work is assigned to the developpers, and they should not work on the same files - most of the time. They have to communicate together if there is a change on some common file. If it is a bigger team, they can use continuous integration to manage the situation. > Other than that, the dynamic view is an interesting tool to make > a workspace visible on multiple machines; normally you'd either > use NFS for that, or in 'commits are cheap and not carved in stone' > VCS systems, you just commit and move that commit over to the target. Yes, that is right. > There is one thing that potentially can cause a *lot* of pain: In Clearcase > the views are always visible at the same path, no matter which > branch/config spec result you're looking on. The software stored in there > can accumulate a lot of reliance on these absolute paths over time, and > they are hard to find during the migration. I dont understand ? >>> From: Andrew Reedick > Because in SVN, you're normally working in a workspace and not directly in the repository. 'svn log' is your 'ct find' in most cases. > Plus, in SVN you're working in a workspace most of the time and the normal command line tools (e.g. find, dir /s) work just fine, > so there's not much need to re-create the wheel with SVN equivalent commands. You need 'ct find' because > all the history is tracked in each individual element, whereas in SVN, history is contained in each (global) revision. > In other words, you're probably trying to apply CC paradigms to SVN. Ok, I will look more carefully to svn+log. > SVN does that. But instead of applying labels to each element, svn simply makes a complete copy (i.e. cp -pr branch1.0 tags/REL_1.0). > In CC terms, it's conceptually similar to adding '-mkbranch REL1.0' to a config_spec and doing a checkout/checkin on each element > to create the REL1.0 branch. And then locking the REL1.0 branch so folks don't check into it. (But SVN's branching/tagging is very efficient and fast.) How do you lock your SVN tags, please ? > You can get the link back to the branch point via 'svn log --stop-on-copy -v -r 1:HEAD -l 1'. (But there is an edge case which breaks that, > requiring iterative use of 'svn log --stop-on-copy'. *grumble*) Nice ! > Back in my day, CC snapshot views were terrible/horrible/nearly_unusable. SVN workspaces are simply great. I doubt your users will complain > once they start using them. IME, the only downside to SVN workspaces/snapshots is that developers will whine about having to checkout a full > directory tree no matter how small the tree. 'svn switch' helps reduce the need to checkout full workspaces, but it still doesn't reduce the whining though. :( Compared
Re: History in subversion
On Jun 16, 2013, at 15:55, Olivier Antoine wrote:
> When you commit, commit can fail, and you might have to merge before
> committing.
If you commit, and the commit fails because one or more of the files you
changed was also changed in the repository, then you have to "svn update" the
working copy to receive the changes from the repository. You do *not* have to,
and probably should not, "svn merge" anything at this point.
> You merge, you did some regression tests on the merged software, and then you
> finally commit.
> But it just mean that the software that you store in the repository is not
> strictly the software that you developped, and this software is simply lost.
> This is just against the SCM principles.
If you're concerned about this, then "svn cp" your trunk to a new feature
branch before beginning your work. Or even after you've finished your work, if
such a situation arises.
Let's say you check out a working copy of trunk. You make changes. You test
them. You commit. The commit succeeds. Good; you're done.
On the other hand, let's say you've made changes and tested them and try to
commit and it fails because a file is out of date. You wish you had made a
feature branch for these changes. No problem; you can still do it now. Use "svn
info" on the working copy to find out what revision of trunk you had checked
out. Let's say it was 1234. Make a feature branch in the repository from that
revision of trunk ("svn cp $REPO/trunk@1234 $REPO/branches/my-feature-branch").
Switch the working copy to that branch ("svn sw
$REPO/branches/my-feature-branch"). Commit the changes; it'll succeed. Now you
have the state of the software you developed recorded in the repository in the
feature branch. Now you can continue with the task of reintegrating the feature
branch into trunk using "svn merge".
Re: History in subversion
On Sun, Jun 16, 2013 at 3:55 PM, Olivier Antoine wrote: > > >Taking the history in a copy is what makes svn work and it makes any >> copied directory functionally usable as a branch or tag. But after >> that it depends on how you actually use it... > > As consequence, SVN allows to create branches and tags on a part of the > software of the repository, starting at a subdirectory and the copy command > can then control/limit the scope of the branch/tag.This can be useful. The common scenario is to have multiple 'projects' under the same repository root, each with their own trunk/branches/tags tree. > Now, I only see two uses of the command svn+copy - and two only : > - Copy the software of the repository - or a part of it - to the branches > or tags repositories, > - Restoring a removed file or directory element to the HEAD revision. > > It is difficult for me to imagine a part (file or whole directory tree) > copied to another place of the same software. This would be some kind of > hardlinks (against SCM principles !). Once you have copied it, it goes its own way but retains previous history - there is nothing wrong with that. Consider a library that evolves as a component of some other project, but you subsequently realize it can be used in several programs that will be maintained separately. It might make sense to copy it up to its own top-level project where it can more sensibly have its own release schedule with its own branches and tags to easily support multiple versions concurrently being used by different things. >> I don't know what I'm missing here. How is it better than explicit >> commit/update/switch operations? What happens if you are disconnected >> while making a change? What if you want your working copy to contain >> conflicts for a while before you can decide how best to resolve them? > > What is nice is : you don't load and you don't update, you just see exactly > what is in the repository. But - I don't like surprises... And I might have temporary local changes in my copy, or have intentionally set up a working copy with mixed revisions. So I guess you'd have to branch in the repository to match what svn does with working copies. > How do you lock your SVN tags, please ? You can use hook scripts for that. We sometimes check out source from tags and commit the resulting binaries back - not exactly 'clean' but pragmatically useful - and possible with an appropriate script that allows this exception. > Now, let me show you something in SVN that is disturbing for me (and other > tool, like RTC, do the same). > > When you commit, commit can fail, and you might have to merge before > committing. If you have concurrent work going on, it is usually best to update before and after your commit. And you'll resolve conflicts in the updates. > You merge, you did some regression tests on the merged software, and then > you finally commit. > But it just mean that the software that you store in the repository is not > strictly the software that you developped, and this software is simply lost. > This is just against the SCM principles. If you want to store all copies of concurrent work instead of just the the way you resolved your updates, you need to be working on separate branches with later resolution. That's the 'feature branch' style and there are sometimes reasons to use it, even though there is some extra overhead. But regardless of the process, you eventually have to resolve conflicting changes. -- Les Mikesell lesmikes...@gmail.com
