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
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 p
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
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 op
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:
> >
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:
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
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 si
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 tru
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 m
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:
> > >
> > &g
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
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 help
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
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,
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.
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
>
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
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]
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
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
[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 SV
[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.reposadmi
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 recei
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, on
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]
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
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 b
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
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
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
> me
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, may
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-
> > tur
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,
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:
>
>
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:
>
>
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:
>
>
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
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 "^
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
>&
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 t
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
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
anoth
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
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&
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
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
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 possib
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
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 accident
50 matches
Mail list logo
