Re: Switching to a specific revision
Nathan Hartman: > Because '-r' tells SVN to look for that path in the HEAD > revision and then follow it back to the specified > revision. > > Try using a peg revision instead: > svn switch ^^/Client/B1/Addons/AddCost/@1431 --ignore-ancestry > > See: http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html Thank you, Nathan. That answers my question. I did not know about peg revisions.
Switching to a specific revision
Hello, all I want to `switch' to a location that existsed in a previous revision, but has since been moved. I invoke: svn switch -r 1431 ^^/Client/B1/Addons/AddCost/ --ignore-ancestry and receive: svn: E160013: '/svn/Sources/!svn/rvr/6932/Client/B1/Addons/AddCost' path not found This path is indeed not present in r6932, but it exists in r1431. Why does SVN try to access the later revision in spite of being told to use 1431?
Re: svn diff -c does not accept HEAD
Nathan Hartman: > A possible rationale is that the HEAD revision could > change without your knowledge (e.g., another user commits > something in the meantime) and you wouldn't get the > revision you were expecting. > > When I want to see the diff of the most recent revision I > use 'svn log -l 1 --diff'. (Note, though, that will be > from the BASE revision, not HEAD.) Thanks for the explanation, Nathan and Daniel, but svn diff -c does not support `BASE' either. Futhermore, from the viewpoint of consistency, it would be natural for -c and -r to accept exactly the same set of values, whose parsing would be implemented in the same piece of code.
svn diff -c does not accept HEAD
Hello, all According to the documentation for svn diff, The -c M option is equivalent to -r N:M where N = M-1 The documation of the -c option agrees: this option is syntactic sugar for -r ARG-1:ARG. I tried it: svn diff -r HEAD:6876 [works] svn diff -c HEAD [fails] The -c option does not support the `HEAD' short-cut in my svn 1.12.0: E205000: Non-numeric change argument (HEAD) given to -c Did I misunderstand the documentaiton, or is it a bug?
Re: Updating source
Nathan Hartman to Anton Shepelev: > > That was my initial suggestion, too, but when I tried `svn up' > > at a random location that was not an SVN working directory it > > printed: > > > > Skipped '.' > > Summary of conflicts: > > Skipped paths: 1 > > > > which is not very polite. I expected: > > > > svn: E155007: 'C:\Program Files\Far Manager' is not a working > > copy > > Interesting. I think you are using an older Subversion client. For > example, Subversion 1.8.14 prints this when I run "svn update" in > a random non-working-copy directory: > > E:\junk>svn up > Skipped '.' > Summary of conflicts: > Skipped paths: 1 > > But Subversion 1.13.0 prints this: > > junk $ svn up > Skipped '.' > svn: E155007: None of the targets are working copies Thank you. I should not have believed the handling of so basic an error has changed so recently. It it time I upgraded my svn client. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Updating source
Nathan Hartman: > If the command line client, are you in a working copy directory > when you run the "svn update" command? That was my initial suggestion, too, but when I tried `svn up' at a random location that was not an SVN working directory it printed: Skipped '.' Summary of conflicts: Skipped paths: 1 which is not very polite. I expected: svn: E155007: 'C:\Program Files\Far Manager' is not a working copy -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Adding a shorthand URL syntax to cwd's URL (was: Re: Automatically supply the origin URL in svn merge)
Daniel Shahaf: > Here are our notes about this from back when the ^/ syntax was > added: > > http://svn.apache.org/viewvc/subversion/trunk/notes/cli-repo-root-relative-support.txt?view=markup#l42 It takes care of cmd.exe, so ^^/ on Windows was a deliberate tradeoff on your part. > Tilde is also special to some shells, at least in the sh/csh > «~username» syntax and in zsh's «foo~bar» syntax (also part of > EXTENDED_GLOB); That is why I proposed a double `~' -- not perfect, of course, but I think none of the major shells will expand it. Of course, if I were designing it from scratch I should try to pick a single ASCII character that none of the common shells treat as special. I am not even sure that such a character exists, does it? > and more generally, there's the consistency > aspect, as you mention. That matters, for example, for scripts > that want to escape arbitrary local paths when calling svn. > Today, the rule is "Append an '@', and if it starts with a > caret-slash then prepend './'."; it would be nice not to break > this. True. > An --option sounds a little too specialized to me. Also, it's a > form of action at a distance (the positional arguments and the > --option's presence would be coupled), whereas the ^/ syntax is > self-contained. Also true, but depends on one's viewpoint. I viewed `svn cp --remote' as a command acting upon the remote repository and `svn cp' as a command acting upon the working directory. In other words -- as a remote and a local command: two different commands with different interpretation of their arguments. Although this view is factally wrong, it helps me understand SVN better, because local operations and sever-side operations are in my opinion very different, even though they fall into the same categories of copy, delete, move, &c. They are like different implementations of the same interface, but I divagate. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Adding a shorthand URL syntax to cwd's URL (was: Re: Automatically supply the origin URL in svn merge)
Daniel Shahaf: > > I had already written about an extension of the caret syntax > > to take the current working directory into account, so that, > > being in svn/trunk/project/xml/ , one does not have to type > > > > svn cp ^/trunk/project/xml/1.xml ^/trunk/project/xml/2.xml > > > > but can simply say: > > > > svn cp ~~/1.xml ~~/2.xml or > > svn cp --remote 1.xml 2.xml > > > > or something else to the same effect, so as not to repeat the > > paths from the repository root. > > > > I don't see where you wrote on this before, Not preserved in Gmane, but it does not matter. > but in any case, this sounds quite reasonable. How about > assigning it the syntax «^./» (caret, dot, slash)? That way we > only have one "special" leading character to worry about. That ^ character must be escaped in Windows, so I don't really like it. My personal (and uneducated) preference of an inexperienced user is to activate CWD URL mode in a cleaner way: either by an option (quite possible, because SVN commands may share options), or via a simpler and shorter syntax than (on Windows) ^^./ . I will, however, be only happy if the caret version is implemented. It is, after all, consistent with the current usage. I think other users of SVN via commadline (instead of the various GUI plugins) should give their opinions and help the maintaners make the correct decision. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Automatically supply the origin URL in svn merge
Daniel Shahaf: > Yes, this feature won't happen unless someone invests time in > making it happen -- but let's not discourage people from > discussing feature ideas even if they may not personally have > time to implement them. Discussions are just as useful a > contribution as patches. It is true that I was not prepared to implement this feature myself when I proposed it. Not having any knowledge of bash or Python, I would have to use SVN from C, which will take me considerable time. I am only learing SVN and giving my feedback about what I think are obvious inefficiencies of its user interface. I had already written about an extension of the caret syntax to take the current working directory into account, so that, being in svn/trunk/project/xml/ , one does not have to type svn cp ^/trunk/project/xml/1.xml ^/trunk/project/xml/2.xml but can simply say: svn cp ~~/1.xml ~~/2.xml or svn cp --remote 1.xml 2.xml or something else to the same effect, so as not to repeat the paths from the repository root. I use SVN at work, so what I ask here is a personal and egoistical request to make my professional life better, but I hope that other users find the proposal convenient too. In return, I am contributing to other free and open-source projects, but not, currently, to SVN. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Automatically supply the origin URL in svn merge
Stefan Sperling: > It's not that simple, as the conflict resolver demonstates. > You're not taking cases into account where multiple copies within > a signle revision correspond to a single deletion. > > So if you want to handle that then you must either error out when > the heuristic fails, or morph 'svn merge' into an interactive > question and answer game with the user, much like the conflict > resolver can behave when it finds ambiguity trying to match up > copies and deletions. I do not think the first usable version should implement such smart logic. Even the most primitive algorithm that uses the source of the last `svn cp', if it has not been `svn rm'ed later, will cover 95% or more of cases when SVN copies are used as true branches, that is as lateral lines of development that are merged back into the trunk when the task is considered complete. OK, let the user specify the source if it has been moved, even though with more work even that can be traced. > All instead of requiring the user to simply type one simple > argument on the command line to run a merge! In a way, yes -- because it is a difference between delegating work to SVN or doing it manually. An SVN developer or contributor can spend, say, five hours and save thousands of hours for the users. > The ultimate goal here is to allow users to type less characters > when starting merges. Not only to type less, but also to think less. In the pure branch usecase, the origin URL may be thought of as being part of the branch metadata, so that sync-merge and reintegraion merge are well-defined without *any* additional arguments: each branch "knows" its parent bow or trunk, from which it sprouts. > Scripting tab-completion for SVN URL arguments into your > favourite shell would also be a usable and effective solution. I do not think it a good idea because there is only one SVN but many shells. There are already similar short-cuts in SVN, such as the caret symbol. They belong to SVN rather than to external automation, because the most basic and frequent operations should be supported natively and in the most efficient manner possible. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Automatically supply the origin URL in svn merge
Daniel Shahaf: > Stefan Sperling wrote on Wed, 25 Mar 2020 15:07 +0100: > > On Wed, Mar 25, 2020 at 04:45:29PM +0300, Anton Shepelev wrote: > > > Why does even the basic sync-merging require that the user > > > specify the source URL, as in: > > > > > > svn merge ^/project/trunk > > > > > > I think this requirement is redundant because SVN know > > > exactly from which original original directory the branch > > > was created by svn cp. Will you consider simplifying the > > > basic merge syntax to: > > > > > > svn merge > > > svn merge > > > > > > so that SVN shall supply the origin URL automatically? Or > > > am I wrong, and my proposal makes no sense? > > > > Recall that SVN cannot know whether a copy operation is > > supposed to create a new branch, or to copy a folder within the > > scope of a branch. This distinction exists only in the human > > mind, not in the tool itself. > > > > Also recall that users have the ability to check out a working > > copy from any level of the tree. > > > > When we combine your idea with the above two aspects of SVN's > > design, we run into a problem. > > > > Example: > > > > svn mkdir ^/trunk > > svn mkdir ^/trunk/dir1 > > svn copy ^/trunk ^/branches/mybranch > > svn copy ^/mybranch/dir1 ^/mybranch/dir2 Stefan, is it by mistake that you omitted `branches': svn copy ^/branches/mybranch/dir1 ^/branches/mybranch/dir2 > > svn checkout ^/mybranch/dir2 my-dir2-working-copy > > cd my-dir2-working-copy > > svn merge > > > > What will happen now? > > Same thing as if the user had run «svn merge ^/mybranch/dir1». Yes. > In general, I understand the proposal as saying that «svn merge» > without arguments would default to looking up the most recent > copy of cwd, and merging into cwd the URL cwd had been copied > from. In my proposal, SVN should search the histrory of the SVN path corresponding to the current working directory for the most recent `svn cp' command with that directory as destination, and use the source of that command as the URL from which to merge. > In your example, I think that would be a reasonable thing to do: > for all we know, the component had been forked (à la libsvn_fs_fs > to libsvn_fs_x, stsp) and the described merge is in fact what the > user wants to do. Futhermore, this is the most basic and most frequent merge scenario, the other ones being *much* rarer. I propose to automate the most frequent use case, for that is the ergonomically right thing to do: make the most frequently needed actions the easiest. > However, I can also see circumstances in which this smartness > could be counter-productive: > > 1. In repository restructurings, such as running «svn merge» in a > working copy of ^/thebarproject/trunk after that project had been > renamed from ^/thefooproject/trunk. Under the proposal, that > would attempt to merge from ^/thefooproject/trunk, and it's not > clear to me that that's a more useful behaviour than just > throwing a usage error. You say the project was renamed, which means that `svn cp' was not involved. Accoring to the description above, my proposal is simply not applicable in this situation. `svn merge' should terminate with the error: "Merge source cannot be automatically determined. Please, specify it on the command line." > 2. We can't trace copies forward. If trunk had been renamed or > forked after the merge, a simplistic "Take the > copyfrom_path@copyfrom_rev, change the copyfrom_rev to 'HEAD', > and use that as the URL to merge from" wouldn't necessarily be > correct. I fear I do not understand this case. Can you please post a sequence of svn commands that reproduce it, even as Stefan did above? > I agree the tool could be smarter if it had notions of "branch > root" and distinctions between "branching", "forking", "copying", > and "renaming"; Like Git? But that would mean more complicated also, and I like SVN for the simplicity of its data model: the evolution of a directory tree, and do not propose to change the fundamentals. > however, I don't think the lack of these distinctions is > necessarily a blocker. It just means we need to be more careful > about not writing automation that will help some cases and > backfire in others. Certainly not. I still hope that my proposal can be made safe. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Automatically supply the origin URL in svn merge
Hello, all Why does even the basic sync-merging require that the user specify the source URL, as in: svn merge ^/project/trunk I think this requirement is redundant because SVN know exactly from which original original directory the branch was created by svn cp. Will you consider simplifying the basic merge syntax to: svn merge svn merge so that SVN shall supply the origin URL automatically? Or am I wrong, and my proposal makes no sense? -- Please, do not forward replies to the list to my e-mail.
Re: Questions about a script for regular backups
Johan Corveleyn >Just to mention another option: Since 1.8 there is the >command 'svnadmin freeze', which locks the repository for >writing while you run another command. That way, you can >use regular backup / copy commands (like rsync) to create a >consistent copy. I think `freeze' is also helpful for atomic runs of `verify' and `hotcopy' in order to ensure you do not accidentally copy a corrupt repository. Without `freeze', how can I make sure that `hotcopy' applies exclusively to verified data? >See the example mentioned in the 1.8 release notes [1]: > > svnadmin freeze /svn/my-repos -- rsync -av /svn/my-repos /backup/my-repos Hmm. I should also expect a simple freeze/unfreeze pair with the caller resposible for unfreezing a fronzen repo... >Of course, in contrast with hotcopy, the original >repository is locked for a (hopefully short) while, so >users might experience errors/timeouts if this takes too >long. This is why I am going to apply it to a mirror kept in sync with the main repo via an incremental hopcopy invoked from the post-commit hook. How can I skip synchronisation of the mirror in the hook if it is currently frozen without making other possible errors? Does SVN provide a reliable lock facility, or must I invent it myself in my backup script/program using e.g. lock files? -- Please, do not forward replies to the list to my e-mail.
Re: Questions about a script for regular backups
I have now set up a post-commit hook that makes an --incremental hotcopy. With the destination on the same machine's HDD, it takes about two seconds, but with a network share it lasts 30 seconds. Is it expected behavior for committing a tiny change in a text file? If not, then where shall I look for the possible performance problems? I have svn 1.8.16. -- Please, do not forward replies to the list to my e-mail.
Re: Questions about a script for regular backups
Thank you for your comments, Andreas: > Literally any situation where the undesired change to be > recovered from happened before this last and single copy > was taken. I am going to prevent this by means of `svnadmin verify': > > Is it practical to call it [verify] daily with a several > > Gb, several thousand-revision repository? > > Again, you don't need to care about how long the backup > takes. Only about it's consistency and the time to restore > in a restore event. Then I propose the following strategy: 1. Maintain a repository mirror by calling svnadmin hotcopy --incremental from a post-commit hook. 2. Store the last verified hot-copy in an archive: a. make a hot copy of the mirror b. verify this secondary hot-copy in order not to lock the mirror for a long time, c. archive the secondary hot-copy in a format with error- correction, such as .rar. I haven't found a free, stable, and easiliy available archiver with built-in error-correcion. Of course, my script will notify the administrator of errors at any step. -- Please, do not forward replies to my e-mail.
Re: Questions about a script for regular backups
Andreas Stieger to Anton Shepelev: > > No, it depends on one's purpose. If it is to keep the > > data in case of HDD crashes, a single mirror is > > sufficient. > > A hobbyist approach this this has lead to many instances > of data loss in serious applications. While planning a backup strategy, one must consider the possible malfunctions and ways to counteract them. How was the data lost in the cases you describe? > > Then again, since an SVN repository maintains its whole > > history, a point-in-time recovery is easily effected by > > `svn up -r N'. > > That is application level (versioning), different from > file level backup. Yes, but it seems largely to withdraw the need of file-level history. All I need is a backup of a recent version of the repository wihout data corruption. > > The only potential problem is some quiet data > > corruption, which is why I ask: will `hotcopy' propagate > > data corruption or will it detect it via internal > > integrity checks and fail? > > Your concern about silent data corruption is not > consistent with your "a copy is a backup" statement. Why > would you care about one while accepting the other? As I said, it is "the only potential problem." > That being said, hotcopy will copy corruptions that may > have happened, even if in the incremental case will only > do so when first processed. svnadmin verify is suitable > for an integrity check. Dumps are very slow. `svnadmin verify' emulates a dump. Is it equally slow? Is it practical to call it daily with a several Gb, several thousand-revision repository? -- Please, do not forward replies to my e-mail.
Re: Questions about a script for regular backups
Andreas Stieger to Anton Shepelev: > > Thanks to everybody for their replies. I now understand > > that -- incremental hot-copies are sufficient for > > regular backups, which can then be mirrored by content- > > aware file- synchronisation tools, but the problem > > remains of preventing an accidental propagation of > > corrupt data into the backup. How do you solve it? > > What the fruit do you mean? The whole purpose of a backup > is that you can restore previous points in time. That > means multiple points in time, whenever the backup > happened to be run. Don't just make a copy and overwrite > it every time. That is just copy, not a backup. Select > backup software that can do that. No, it depends on one's purpose. If it is to keep the data in case of HDD crashes, a single mirror is sufficient. Then again, since an SVN repository maintains its whole history, a point-in-time recovery is easily effected by `svn up -r N'. The only potential problem is some quiet data corruption, which is why I ask: will `hotcopy' propagate data corruption or will it detect it via internal integrity checks and fail? -- Please, do not forward replies to my e-mail.
Re: Questions about a script for regular backups
Thanks to everybody for their replies. I now understand that --incremental hot-copies are sufficient for regular backups, which can then be mirrored by content-aware file- synchronisation tools, but the problem remains of preventing an accidental propagation of corrupt data into the backup. How do you solve it? -- Please, do not forward replies to my e-mail.
Re: Questions about a script for regular backups
Mark Phippard: >Almost no one uses the BDB repository format. The fsfs >format became the default in SVN 1.1 or 1.2 and it is the >only format used anymore. Phew. We do have FSFS. Thank you. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Questions about a script for regular backups
Mark Phippard to Anton Shepelev about hot copies: >>Are they portable across operating systems and >>filesystems? (I fear not) > >Yes, they are absolutely portable across OS and FS. As is >the repos itself. The only issue when going across these >is managing the OS level permissions of the copy. IOW, if >you run something as root the copy will tend to be owned by >root which might make it not ready for consumption without >a chown/chmod. > >I used to regular move fsfs repositories between an AS/400 >EBCDIC server and Windows without issue. But SVN book has this: As described in the section called "Berkeley DB", hot- copied Berkeley DB repositories are not portable across operating systems, nor will they work on machines with a different "endianness" than the machine where they were created. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Questions about a script for regular backups
Mark Phippard: >My first choice option would be to setup a repository on a >second server and use svnsync from a post-commit hook >script to sync the change. After that, I would use >svnadmin hotcopy with the new --incremental option (as of >1.8?). Dump is not a great choice for backups. Thank you, but I should prefer a traditional backup approach. You and other posters say that dumps are poor choice, so I shall backup incremental hot copies. But the question remains that I have asked already in another reply: are hot-copies a reliable means of long-term storage. Cannot they become obsolete when a new version of SVN comes out? Are they portable across operating systems and filesystems? (I fear not) -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Questions about a script for regular backups
[replying via Gmane] Andreas Stieger: >The dump format is not the best option for backups. The >restore time is much too slow as you need to recover from a >serialized format. In many hand-baked scripts the dump >method misses point-in-time recovery capabilities, -> Why should I need those if SVN repositories store the complete history? >-> and few people implement backup usability checks by >loading the dump. Is not a dump guarranteed to be usable if `svn dump' succeeded? If not, how do I load that dump without intefering with the current work? >If you have content-aware file based backup software >available use that in the on-disk repository format. The Unison file synchroniser, to work efficeintly on Windows, has an option to use file size and modification date to detect changes. Would that work with SVN? Do you suggest that I backup the contents of csvn\data\repositories >Just make sure you take a consistent snapshot, which can be >achieved by briefly locking it (svnadmin lock) or operating >on a consistent copy (svnadmin hotcopy). Is a hot-copy portable between SVN versions? How safe is it to rely on a hot copy instead of a dump? -- Please, do not forward replies to the list to my e-mail.
Questions about a script for regular backups
[Having failed to post this message via Gmane, I am sending it by e-mail] Hello, all In order to write a backup script in the Windows batch language, I was reading the section "Migrating Repository Data Elsewhere" from "Repository Maintenance": http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html where I found the following interesting paragraph: Another neat trick you can perform with this --incremental option involves appending to an existing dump file a new range of dumped revisions. For example, you might have a post-commit hook that simply appends the repository dump of the single revision that triggered the hook. Or you might have a script that runs nightly to append dump file data for all the revisions that were added to the repository since the last time the script ran. Used like this, svnadmin dump can be one way to back up changes to your repository over time in case of a system crash or some other catastrophic event. The book unfortunately does not seem to give any examples of this usage, leaving the following questions: 1. Is "appending" to be understood literally, that is using the >> operator on a previously existing dump file, or is it a figure of speach describing a supplementary dump file that shall be applied "on top" of a previous one? 2. How does one determine the revision range for a routine incremental dump -- by calling `svnlook youngest' before dumping? 3. Must the backup script somehow store the last revision in the dump between calls? If so, I shall have to keep in a file and not let anybody touch it. -- Please, do not forward replies to the list to my e-mail.
Re: Viewing the woking copy of a lock
Daniel Shahaf: > And for future reference, you can have your users lock > files using something along the lines of `svn lock -m > "$(hostname):$(pwd)' to be able to answer your question. > You could even enforce this with a pre-lock hook. Thank you, Daniel. Since the pre-lock hook does not receive the actual working directory I can only theck the syntax of such a comment, but I will bear the option in mind. -- Please, do not forward replies to my e-mail.
Re: Viewing the woking copy of a lock
Lorenz to Anton Shepelev: >>How can I view the working-copy path with which a >>lock is associated, given the information about >>the lock from `svnadmin lslocks'? > >you can't. The server knows nothing about the >working copy and its location, only about the user. > >If you know the working copy, you could run "svn >info" on all occurences of the file, to identify >the working copy. I think it one of the rare cases when dear old SourceSafe was better, but of course we should reor- gaise our process to avoid situations when this functinality is desired. -- Please, do not forward replies to the list to my e-mail.
Viewing the woking copy of a lock
Hello, all How can I view the working-copy path with which a lock is associated, given the information about the lock from `svnadmin lslocks'? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Re: Reintragration using 'swtich'
Daniel Shahaf to Anton Shepelev: >>Is the wroking copy of the branch not required for >>reintegration? > >It's not required. You can 'switch' your working copy to >trunk and run Thank you. Can you please tell me what happens to uncommitted changes in the working copy during a 'switch'? -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Reintragration using 'swtich'
Hello, all I have created a new branch on the server using the ^ notation, switched to it from my trunk, and made some changes. Now, in order to reintegrate, the manual says I need a working copy of the trunk, and that I can obtain one using 'switch'. If I, howev- er, I swtich locally back to the trunk, I will lose the branch working copy. Is the wroking copy of the branch not required for reintegration? -- Please, do not forward replies to the list to my e-mail.
Re: 'svn cp' disregards svn:needs-lock on Windows
Brane to Anton Shepelev: > > Is it an error or expected behavior that local > > attribute to the copies of files that have the > > svn:needs-lock property and are marked as read- > > only in the woking copy at their original loca- > > tions? > > It's expected. The new file is essentially in a > 'modified' state, even though it's contents have > not changed. Does not this violate the requirement to lock a file *prior* to modifying it? > After you commit it, it will become read-only in > the working copy. No, it does not. Only after I delete the file and update it, does SVN "restore" it with the read-only attribute. -- Please, do not forward replies to my e-mail.
'svn cp' disregards svn:needs-lock on Windows
Hello, all Is it an error or expected behavior that local 'svn cp' on Windows does not assign the read-only attribute to the copies of files that have the svn:needs-lock property and are marked as read-only in the woking copy at their original locations? -- Please, do not forward replies to my e-mail.
Re: Problem with merge --reintegrate
Stefan Sperling to Anton Shepelev: > > The problem is still there with svn client > > 1.9.7. > > If your problem is rooted in issue #4582 then > 1.8.x clients have already created svn:mergeinfo > properties which now confuse the reintegrate > merge. > > Update *all* your clients to 1.9.7, and the issue > should disappear with new branches created and > managed with these up-to-date clients. > > You can keep using your workaround (expand the > working copy entirely) for all existing branches. > > In case the problem re-appears with a branch that > was only touched by 1.9.7 clients, please let us > know. Thank you, Stefan, I will. -- Please, do not forward replies to my e-mail.
Re: Problem with merge --reintegrate
Johan Corveleyn: > This issue seems similar: > https://issues.apache.org/jira/plugins/servlet/mobile#issue/SVN-4582 > > I found this in the list of CHANGES [1] for 1.9.0 > (I went looking there, because I vaguely remem- > bered seeing the issue before). So try again with > a 1.9.x client, maybe there it's fixed. The problem is still there with svn client 1.9.7. I did not upgrade any server components though. Is it a dangerous operation? -- Please, do not forward replies to my e-mail.
Re: Problem with merge --reintegrate
Mark Phippard to Anton Shepelev: > > Stefan Sperling: > > > > > Which version of svn are you using to run this > > > merge? > > > > 1.8.17 (r1770682) as part of CollabNet SVN. I > > am not at all certain we need its extra fea- > > tures, but someone else has decided to use that. > > FWIW, that is just normal Subversion. It is just > the binaries CollabNet built, packed and tested. > There are no customizations applied to it. I > think that is generally true of everyone that > builds and packages Subversion binaries. I fear we have SubversionEdge. -- Please, do not forward replies to my e-mail.
Re: Problem with merge --reintegrate
Stefan Sperling: > Which version of svn are you using to run this > merge? 1.8.17 (r1770682) as part of CollabNet SVN. I am not at all certain we need its extra features, but someone else has decided to use that. Shall I forward my replies to your e-mail, as you do yours? -- Please, do not forward replies to my e-mail.
Re: Problem with merge --reintegrate
I wrote: > I am having trouble reintegrating my fresh and > short-lived test branch (called progbar). Al- > though there have been no changes to the trunk > since the creation of the branch from revision > 2324, > >svn merge "^/branches/progbar" --reintegrate > > gives: > >svn: E195012: Unable to find repository location for >'svn/Sources/trunk' in revision 1823 > > trunk indeed was not created until revision 2252, > but I wonder why can SVN be interested in revision > 1823, if I created my test branch by copying revi- > sion 2524 of the trunk: > [...] This problem is somehow conntected with sparse di- rectories. If I update the working copy of trunk so that it has the file affected in 1823, reintegration completes successfully, but that file is not modifed and is not shown by 'svn diff' after 'svn merge --reintegrate'. Now can bypass the problem, but I should like to know why it occurs in the first place, so I have re- verted the merge and can reproduce it again. I will appreciate your help in tracking-down its cause. -- Please, do not forward replies to my e-mail.
Re: Problem with merge --reintegrate
I wrote: > I am having trouble reintegrating my fresh and > short-lived test branch (called progbar). Al- > though there have been no changes to the trunk > since the creation of the branch from revision > 2324, > >svn merge "^/branches/progbar" --reintegrate > > gives: > >svn: E195012: Unable to find repository location for >'svn/Sources/trunk' in revision 1823 > > trunk indeed was not created until revision 2252, > but I wonder why can SVN be interested in revision > 1823, if I created my test branch by copying revi- > sion 2524 of the trunk: > [...] 'svn diff' between branch and trunk shows only the two files that I modified in the branch, of which neither was touched in revision 1823. Sorry for three messages instead of one. -- Please, do not forward replies to my e-mail.
Re: Problem with merge --reintegrate
I wrote: > I am having trouble reintegrating my fresh and > short-lived test branch (called progbar). Al- > though there have been no changes to the trunk > since the creation of the branch from revision > 2324, > >svn merge "^/branches/progbar" --reintegrate > > gives: > >svn: E195012: Unable to find repository location for >'svn/Sources/trunk' in revision 1823 > > trunk indeed was not created until revision 2252, > but I wonder why can SVN be interested in revision > 1823, if I created my test branch by copying revi- > sion 2524 of the trunk: > [...] Revision 1823 contains a change that is in no way connected with the changes I made in my branch. I did not even download that directory to either the trunk or branch parts of my working copy. -- Please, do not forward replies to my e-mail.
Problem with merge --reintegrate
Hello, all I am having trouble reintegrating my fresh and short-lived test branch (called progbar). Although there have been no changes to the trunk since the creation of the branch from revision 2524, svn merge "^/branches/progbar" --reintegrate gives: svn: E195012: Unable to find repository location for 'svn/Sources/trunk' in revision 1823 trunk indeed was not created until revision 2252, but I wonder why can SVN be interested in revision 1823, if I created my test branch by copying revi- sion 2524 of the trunk: r2325 | GIT\Anton | 2017-12-23 16:54:44 +0300 | 1 line Work done, merging with trunk to prepare for release. r2324 | GIT\Anton | 2017-12-23 16:43:25 +0300 | 1 line Branch for progressbar modifications. What I did was: 1. 'svn cp' of trunk into the new branch, 2. modify branch and commit the changes, 3. merge changes from the trunk into branch (there were none) 4. go to trunk and merge changes form the branch with --reintegrate. I did all this over the course of an hour, on a hol- iday, when nobody else was working. -- Please, do not forward replies to my e-mail.
Re: Deduce the server URL from the current directory inside the working copy
I wrote to Daniel Widenfalk: >>>I find it mildly annoying to type the full path >>>within a repository for server-side file opera- >>>tions, such as 'delete' and 'copy'. Observe >>>that, being on Windows, I must use quotes in or- >>>der to escape the caret character: >>> >>> svn rm "^/A/B/C/file.txt" >>> >>>Is there a way to avoid the entry of the full >>>path when invoking this command from A/B/C/ in a >>>working copy? In other words, I should like to >>>have some syntax that told SVN to use the full >>>sever-side path of a file using the current di- >>>rectory within a working copy. For example, in- >>>stead of writing: >>> >>> svn rm "^/A/B/C/file.txt" >>> >>>I could: >>> >>> cd Work/A/B/C >>> svn rm "^^file.txt" >> >>Could you explain why you'd want to do a server- >>side operation on something which is locally ac- >>cessible? I.e. why not do? >> >>$ cd A/B/C >>$ svn rm file.txt >>$ svn commit -m "Another fancy message" > >To save time and HDD load, easier to simplify the >use of server-side 'svn info' e.g. to view lock in- >formation, &c. 'svn ls' kind of does it already... I think it would be a natural extension of the caren syntax. -- Please, do not forward replies to the list to my e-mail.
Re: Deduce the server URL from the current directory inside the working copy
Daniel Widenfalk to Anton Shepelev: >>I find it mildly annoying to type the full path >>within a repository for server-side file opera- >>tions, such as 'delete' and 'copy'. Observe that, >>being on Windows, I must use quotes in order to >>escape the caret character: >> >> svn rm "^/A/B/C/file.txt" >> >>Is there a way to avoid the entry of the full path >>when invoking this command from A/B/C/ in a work- >>ing copy? In other words, I should like to have >>some syntax that told SVN to use the full sever- >>side path of a file using the current directory >>within a working copy. For example, instead of >>writing: >> >> svn rm "^/A/B/C/file.txt" >> >>I could: >> >> cd Work/A/B/C >> svn rm "^^file.txt" > >On Windows you'd use a double-carret to quote it, >i.e: > >$ svn rm -m "fancy message goes here" ^^/A/B/C/file.txt Thank you. >Could you explain why you'd want to do a server- >side operation on something which is locally acces- >sible? I.e. why not do? > >$ cd A/B/C >$ svn rm file.txt >$ svn commit -m "Another fancy message" To save time and HDD load, easier to simplify the use of server-side 'svn info' e.g. to view lock in- formation, &c. 'svn ls' kind of does it already... -- Please, do not forward replies to the list to my e-mail.
Deduce the server URL from the current directory inside the working copy
Hello, all I find it mildly annoying to type the full path within a repository for server-side file operations, such as 'delete' and 'copy'. Observe that, being on Windows, I must use quotes in order to escape the caret character: svn rm "^/A/B/C/file.txt" Is there a way to avoid the entry of the full path when invoking this command from A/B/C/ in a working copy? In other words, I should like to have some syntax that told SVN to use the full sever-side path of a file using the current directory within a work- ing copy. For example, instead of writing: svn rm "^/A/B/C/file.txt" I could: cd Work/A/B/C svn rm "^^file.txt" -- Please, do not forward replies to the list to my e-mail.
Re: svn:ignore
Ryan Schmidt to Anton Shepelev: >>I have now another question: how do I specify several >>ignore pattern on the Windows commandline? I have no idea >>how to pass a list of new-line separated values. > >I'd use "svn propedit", and not specify a value on the >command line; this will open your editor. Thank you, Ryan. -- Please, do not forward replies to the list to my e-mail.
Re: svn:ignore
I wrote: >Now, when I modify file.txt, svn still detects the >modification and has no problem commiting it. What am I >doing wrong? > >I expect that it will ignore changes to file.txt. If not, >what is the purpose of svn:ignore? Got it -- it applies at the moment of 'svn add'. I have now another question: how do I specify several ignore pattern on the Windows commandline? I have no idea how to pass a list of new-line separated values. -- Please, do not forward replies to the list to my e-mail.
svn:ignore
Hello, all I can't seem to understand the usage of the svn:ignore property. I have a directory DIR with a file file.txt in it, which I want ignored. I entered DIR, and typed: svn propset svn:ignore file.txt . svn ci . Now, when I modify file.txt, svn still detects the modification and has no problem commiting it. What am I doing wrong? I expect that it will ignore changes to file.txt. If not, what is the purpose of svn:ignore? -- Please, do not forward replies to the list to my e-mail.
Re: 'svn ls' not showing the contents of the repository
Daniel Shahaf to Anton Shepelev: > > Why can 'svn ls' show different results when invoked > > from two working copies of the same repository? > > Probably because the working copy's BASE revision is > different. 'svn ls' runs 'svn ls .@BASE' by default. Disregarding what is writ in the Book? > If you pass an explicit revision you'll get identical > output: 'svn ls -r HEAD'. So I must either commit or update the whole working copy in order for the new directory to become availble for download to the workng copy? > This could also be caused by authz settings. Impossible. -- Please, do not forward replies to my e-mail.
'svn ls' not showing the contents of the repository
Hello, all Why can 'svn ls' show different results when invoked from two working copies of the same repository? According to the documentation is should always list the acutal contents of the corresponding repository: The default TARGET is ., meaning the repository URL of the current working copy directory. 'svn info' from both the working copies returns: URL: http://sbo-prod1:18080/svn/Sources so why the outout of 'svn ls' is not the same? In the working copy that I checked-out later it shows some newly added directories that it does not "see" from within the older working copy. When I invoke: svn ls http://sbo-prod1:18080/svn/Sources from the older working copy the output is as expected. -- Please, do not forward replies to the list to my e-mail.
Re: Implementing the Lock->Edit->Unlock cycle
Andreas Krey: >If you plan doing massive work in a module, you >need to talk to the other people working in the >same module anyway, as they would be annoyed if you >locked the file, and they can't do planned work. OK. >Ideally the other people do their commits in small >increments as well, and you could go and try to >merge their work to see if that works or starts to >fall apart. (Even more ideally you'd get notifica- >tions if other people commit changes that happen in >parallel to yours, and will need to be merged.) Those could be implemented via hooks, but how shall one determine whether a person is currently working on some file or not, lest he be swarmed by irrele- vant notifications? >>As I understand, it requires customization of the >>svn client so that whenever asked to unlock a file >>it shall update it also. Is it possible? > >No. SVN clients may not even be online at that >time. Also I would seriously *not* want files to >change in my workspace e.g under a test run. But I meant that for locks issued locally via the working copy. >Actually, we use svn for such purposes (non-mer- >gable files), and git for regular sources. So do you always update and then lock while commenc- ing work on a non-mergeable file, or do you invoke this sequence via a single mouse-click or a key- press? -- Please, do not send replies to the list to my e-mail.
Re: Implementing the Lock->Edit->Unlock cycle
Lorenz to Anton Shepelev: >>We are migrating to SVN from the dreaded SourceSafe >>and should like to retain, if only at the start, the >>exclusive check-out process, with the following >>*atomic* operations which should be performed as >>easily as possible: >> >> 1. lock and update, >> lest one might accidentally start editing an >> old version of some file. >>[...] > >"svn lock" will fail if your working copy is not up >to date. > >So using svn:needs-lock and an editor that prevents >you from modifying read-only files should do the job. Thanks. -- Please, do not send replies to the list to my e-mail.
Re: Implementing the Lock->Edit->Unlock cycle
Thanks to everybody for their replies. Eric Johnson to Anton Shepelev: >>> 1. lock and update, >>> lest one might accidentally start editing an >>> old version of some file. > >Subversion supports locks. However, it sounds like >they do not work the way you want them to. > >Subversion's locks do not prevent anyone from edit- >ing files. They merely slow other people, besides >the owner of the lock, from committing changes. But the svn:needs-lock property helps somewhat. >"svn update" is your friend. Just encourage users >to do updates before they start editing. Is there no protection against an oblivious users's losing a day's work merely because he forgot to up- date his working copy, which was obsolete beyond merging? I should like svn to update the local copy automati- cally once the lock is issued, but it seems impossi- ble via server-side hooks, for they don't have ac- cess the user's woking copy where the file must be updated. If am right about it, is there any mecha- nism to cause SVN to update the local file every time it is locked? As I understand, it requires customization of the svn client so that whenever asked to unlock a file it shall update it also. Is it possible? >Also, the lock-before-edit approach doesn't actual- >ly solve the problem of making sure users have the >latest. My recollection from using VSS was that >integration problems showed up more frequently, not >less. I think this was from the illusion that I >have the latest version of the file I want to edit >(since I got the lock), so my files are probably >all going to be consistent. VSS guarantees that you are editing the latest ver- sion of the file, unless, of course, you have ex- plicitly overriden the readonly attribute. The oth- er files, both dependent and depending, may be obso- lete though. >In practice, other developers change APIs, and I >only discover that by keeping current on the latest >code changes. That may happen, but it is only one half of the proglem, and actually less than that in my case, where the interfaces change less frequently than the implementations, which is a good thing. >>>2. commit and unlock. >>Commits and locks are independent. > >Commits and locks are independent. In SVN's inteded process, yes, but they are not in the lock-edit-unlock cycle. >I suspect you could tie yourself up into knots try- >ing to write hook scripts that accomplish some of >what you want, -> I hope hooks are not that hard... >-> but by the time you get them working just the >way you think you want them, you'll discover that >you probably don't want them that way. Maybe, but I am under peer pressure, and TFS is the alternative, and I think we still need it at least for "binary" files such as MS Word documents. I wish we maintained documentaion in Texinfo, LaTeX, of Troff, but am helpless in this regard. -- Please, do not send replies to the list to my e-mail.
Implementing the Lock->Edit->Unlock cycle
Hello, all We are migrating to SVN from the dreaded SourceSafe and should like to retain, if only at the start, the exclusive check-out process, with the following *atomic* operations which should be performed as easily as possible: 1. lock and update, lest one might accidentally start editing an old version of some file. 2. commit and unlock. Can SVN be configured to have such operations, and how? We plan to use it mainly from the AnkhSVN plugin for Visual Studio, but I think the question belongs here.
