Hi Michael,
to cite another author, "Don't panic!" :-)
It is quite difficult to actually lose data with Subversion, so your changes
and those of your wife are most likely still somewhere inside the "bit bucket
abbys" (aka a Subversion repository). It's just a question of how to get them
back.
Hi Dan,
I just tried this on OS X (using svn 1.8.0) and I'm able to create a directory
in the repository with a backslash in its name and delete it again.
My guess would be that this works on other UNIXes as well. So if you have
access to a non-Windows machine, delete or rename the directory fro
Grrr. That would have to be
svn mv -m "..." "http://svr/sandbox/A\B"; "http://svr/sandbox/AB";
of course. Sorry.
On 07.05.2014, at 18:11, Tobias Bading wrote:
> Umm, forgot the obvious: Did you try to rename the directory directly in the
> repository, e.g.
Umm, forgot the obvious: Did you try to rename the directory directly in the
repository, e.g. using
svn mv -m "..." "http://svr/sandbox/A\B/bar1.c"; "http://svr/sandbox/AB/bar1.c";?
Tobias
On 07.05.2014, at 18:04, Tobias Bading wrote:
> Hi Dan,
>
> I j
On 19.04.2014, at 13:44, Zé wrote:
> On 04/18/2014 04:41 PM, Bob Archer wrote:
>>> Does subversion provide a way for the user to configure his username, thus
>>> avoiding having to pass the --username flag everytime he has to commit
>>> something?
>>>
>>> Thanks
>>> Zé
>>
>> The credentials shoul
On 09.04.2014 12:19, Stefan Sperling wrote:
> On Wed, Apr 09, 2014 at 11:46:05AM +0200, Tobias Bading wrote:
>> Hi,
>>
>> follow-up regarding my problems with "database is locked" errors
when trying
>> to access a Subversion 1.8 working copy located on an AIX
Hi,
follow-up regarding my problems with "database is locked" errors when trying
to access a Subversion 1.8 working copy located on an AIX machine
remotely via
SMB from a GNU/Linux machine:
- A Windows SMB share causes the same errors, so it's not specific to Samba.
- The problem can be circu
On 03.04.2014, at 19:46, Philip Martin wrote:
> Tobias Bading writes:
>
>> fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, len=1})
>> = 0
>> fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741826,
>> len=510}) = 0
>> fcn
On 03.04.2014, at 19:28, Stefan Sperling wrote:
> On Thu, Apr 03, 2014 at 07:12:26PM +0200, Tobias Bading wrote:
>> I'm quite sure Emacs doesn't fork more than one svn child process in
>> parallel,
>
> It doesn't matter how many clients emacs is forking.
>
On 03.04.2014, at 17:24, Branko Čibej wrote:
> On 03.04.2014 17:06, Tobias Bading wrote:
>> Hi.
>>
>> I'm having a problem with a workflow that used to work fine with Subversion
>> 1.6 but stopped working with Subversion 1.8:
>>
>> I'm using G
Hi.
I'm having a problem with a workflow that used to work fine with Subversion
1.6 but stopped working with Subversion 1.8:
I'm using GNU Emacs on an Ubuntu Lucid machine to edit files on an AIX
machine
over a SMB share. Emacs uses the Subversion 1.8.8 command line client to
perform vc-relate
On 20.07.2013, at 17:08, Tobias Bading wrote:
> Hello Berry,
Ooops. Sorry, Karl. Seems that for a second I thought you were Bajoran. ;-)
On 20.07.2013, at 01:18, Karl Berry wrote:
> The vc-svn.el file at
> http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/emacs/vc-svn.el
> for svn support in Emacs 21 broke with the change in Subversion that
> puts .svn only at the top level of a repository. Now the
> (vc-svn-regi
On 08.07.2013 10:24, Miro Kropáček wrote:
Hi Tobias,
You're right, a simple 'svn update' in 'trunk' or 'software'
should not pull in any directories of files outside of 'user'.
That should only happen if you run e.g. 'svn update --set-depth
infinity'. What Subversion version are
On 08.07.2013 01:06, Miro Kropáček wrote:
Hello,
I'm not subscribed to the list. I'd like to ask about one issue I'm
having. Let's say I've got a tree like this:
server/svn/trunk/software
server/svn/trunk/software/user
server/svn/trunk/software/wicked_filenames
server/svn/trunk/documentation
Goody #2: (People probably came up with something like this for
Subversion 1.7 already... anyway...)
Our company currently uses Subversion 1.6 and at first I thought
'duel-Subversioning' 1.6 and 1.8 would lead nowhere except headaches. As
it turns out, the fact that a Subversion 1.8 client can
Hi *,
I'm currently checking out (no pun intended) Subversion 1.8 RC2 and
thought a "Subversion 1.8 goodies" thread might be fun. Here we go...
Goodie #1:
Are you multitasking all day long?
Are you tired of remembering all those fancy changelist names you came
up with to keep the chaos in ch
On 28.05.2013 15:24, Tobias Bading wrote:
> On 28.05.2013 15:15, Philip Martin wrote:
>> Are you running some non-standard kernel?
>
> Depends on your definition of 'standard'. ;-)
> I'm using the default kernel linux-image-2.6.32-46-generic from the
Ubuntu Luci
On 28.05.2013 15:15, Philip Martin wrote:
Are you running some non-standard kernel?
Depends on your definition of 'standard'. ;-)
I'm using the default kernel linux-image-2.6.32-46-generic from the
Ubuntu Lucid repositories.
On 28.05.2013 14:31, Philip Martin wrote:
Tobias Bading writes:
b) '{ while true; do echo "">t; ls -l --full-time t; rm t; done; } |
uniq' prints exactly *two* lines per second, one every 0.5 seconds,
exact down to the millisecond.
I have an Ubuntu 12.04 machine
On 28.05.2013 12:54, Philip Martin wrote:
Tobias Bading writes:
On 27.05.2013 16:12, Tobias Bading wrote:
On 27.05.2013 16:01, Branko Čibej wrote:
Can you try this: run the following command for a couple of seconds, it
should give you an idea about the system clock precision.
{ while true
On 27.05.2013 16:12, Tobias Bading wrote:
On 27.05.2013 16:01, Branko Čibej wrote:
Can you try this: run the following command for a couple of seconds, it
should give you an idea about the system clock precision.
{ while true; do date '+%M:%S.%N'; done; } | uniq
Redirected to a f
On 27.05.2013 16:01, Branko Čibej wrote:
Can you try this: run the following command for a couple of seconds, it
should give you an idea about the system clock precision.
{ while true; do date '+%M:%S.%N'; done; } | uniq
Redirected to a file, I get about 1250 unique timestamps per second,
nic
On 27.05.2013 12:43, Branko Čibej wrote:
On 27.05.2013 09:59, Tobias Bading wrote:
Quick update:
The problem is definitely timestamp related. "touch 3449_spurious"
fixes a "corrupt" working copy, i.e. "svn status" and "svn diff" work
properly afterwards.
Another update:
Tried to build against latest apr-1.4.6.tar.bz2 & apr-util-1.5.2.tar.bz2
instead of the older versions from the Ubuntu Lucid repositories. No
change :-(, i.e. the test fails with the original
svn_io_sleep_for_timestamps implementation.
Next update:
With a plain & simple
void
svn_io_sleep_for_timestamps(const char *path, apr_pool_t *pool)
{
apr_sleep(101);
}
in libsvn_subr/io.c the test is running slower, but works every time.
Quick update:
The problem is definitely timestamp related. "touch 3449_spurious" fixes
a "corrupt" working copy, i.e. "svn status" and "svn diff" work properly
afterwards. I'll try to figure out why my machine is living in its own
timeline. All I can say after reading just a few lines of python
Hi Branko & Philip,
thanks a lot for your hints. I've seen your mails only now on
http://mail-archives.apache.org/ and won't have access to my GNU/Linux machine
till Monday. Meanwhile I'm giving 1.8 RC2 a try on Mac OS Snow Leopard.
What do you mean by "sleep for timestamps disabled"? I didn't
Hi Philip,
thanks for your suggestions. I tried to dig a little deeper... and now
things are getting even more strange.
First, I tried to delete everything after the "update -r2" from
no_spurious_conflict so I could make a copy of the wc before the merge.
Guess what? Executing the "merge -c4
Hello everyone,
I'm having a bit of trouble with subversion-1.8.0-rc2 on my Ubuntu Lucid
(x86_64) machine. "make check" or "./diff_tests.py 60" (in directory
subversion/tests/cmdline) fails with:
---
W: =
Expected '3449_spurious' an
30 matches
Mail list logo
