Thanks Bert for your answer. I've used the latest tortoisehg which used to
ship the subversion bindings but stopped to do so. That is entirely
documented here:
https://bitbucket.org/tortoisehg/thg/wiki/libsvn
The server on the other ends dates back to 2011. I believe it is something
along 1.4, bu
http://lmgtfy.com/?q=git+to+svn
2013/6/3 EricD
> Can I migrate from GIT to SVN ?
>
> I didn't find any good procedure on the web.
>
--
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C
>> The problem may be levered by recursively comparing the repository UID
>and
>> the relative path in the uri when the external is resolved. Proofing that
>> this check would be enough is left to the reader. :-)
>
>This will catch the "simple" case when an external includes its own parent
>directo
>http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=
>2939615
>>
>> Do you think svn checkout should be defensive against recursive externals
>?
>
>At elego (where I work) we actually use this as a trick question during
>Subversion workshops. People who don't necessarily kno
>> 1. It shows locked status even other people not being used it in
>> Lock.
>>
>> 2. I will have to run CleanUp command , Why?
>>
Good morning,
I ran into this problem recently, too.
First: So far I can tell that there might be some circumstances where the
working copy is left locke
FWIW, my observations are that an incomplete working copy is usually
*broken* and one has to do a fresh checkout. Mostly this happens when the
.svn meta-files do no longer match the working copy files. This usecase
_can_ happen when a program holds an exclusive lock on a file and one runs
"svn up"
>If I look in /var/log/messages on my client machine, I see this:
>{{{
>Oct 20 21:00:48 andLinux -- MARK --
>Oct 20 21:20:48 andLinux -- MARK --
>Oct 20 21:40:48 andLinux -- MARK --
>Oct 20 22:00:49 andLinux -- MARK --
>Oct 20 22:21:09 andLinux -- MARK --
>Oct 20 22:41:37 andLinux -- MARK --
>Oct 2
See:
$svn list
Directories should all match against the regular expression .*/$
Someone else feel free to correct me if I'm spreading bullsh*t. :-)
--
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B46
>And the product name is ...
If I remembered, I would have posted it. It was _probably_ WANdisco.. please
use your favourite web search engine to find out more.
Regards,
D.
Im unsure if this really matters, but there exists a commercial product
that enables svn morroring with writeable mirrors by using the paxos
algorithm.
_
From: yasith tharindu [mailto:yasithu...@gmail.com]
Sent: Thursday, October 06, 2011 1:03 PM
To: Thorsten Schöning
Cc: users@subve
>Yes I did, and this is my deduction also. The user names won't make it
>to the pre-commit unless they're required to authenticate by svnserve
>first.
I'm not an svnserve expert, please don't expect help there. All I can say
is, that you could try to set up subversion within apache. Then it shoul
This procedure could be easily automated by a stupid script that does
something like:
for REV in seq 0 NEWESTREV; do
svn up -r REV
cp updated-file repos-file
if [ -z "`svn diff`" ]; then echo "found candidate rev $REV!"; fi
svn revert .
done
JMTC,
D.
>-Origina
>I tried this, but an author is not passed unless auth-access is in use
>AFAICT. So $USER in your example is always empty.
This would mean that you would never see any usernames in commits. Did you
try to commit using the --username parameter?
>I'm trying to force commits to have an attached author, but I don't
>care for requiring passwords. In other words, commits should contain
>an author field but there's no enforcing that the committer is who
>they claim to be.
>
>I've tried filtering for an author in the pre-commit hook, but the
>us
>[snip]
>> Subversion is still an observer and whatever a user does, he must tell
>> Subversion what he did in cases where subversion can't
>> understand it by
>> itself (i.e. file/folder rename/move that preserve history across the
>> revisions). Every VCS I know works like this. Maybe one invents
>I'm not sure you understand the kinds problems the new working copy
>format is settling.
For me it settles the major problem of multiple .svn folders in a checkout.
> You must still use svn commands instead of OS
>commands in 1.7. That won't change. I don't think it will ever change.
>The reason
>Then you must explain it to them. :) To move or delete items in a working
>copy, you must use svn commands. You must not use OS commands. That's just
>how it is.
This is going to be a long journey. *jokingly*
Thanks for the insights and incredibly fast answers! It's awesome that
you're working o
>I doubt it. Or rather, the behavior is not broken. The user is broken. As I
>said: "svn commit foo" should have worked fine if you had not run "rmdir
>foo" beforehand. Don't run "rmdir foo". Just run "svn rm foo" followed by
>"svn commit foo" and everything should work.
True - it's nothing totall
>> I think SVN is behaving correctly. When you do svn commit foo you're
>telling Subversion to commit changes made in foo. There are no changes in
>foo because it's been deleted. The changes, instead, are in its parent
>directory, the one from where you issued your commands. That's why svn
>commi w
>You could also delete the directory directly in the repository using "svn
>delete -m ". This way you would avoid the problem of
>committing partial changes of your working copy.
.. which is just another workaround.
Hi,
having a fresh subversion repository doing this as preparation:
$ mkdir foo/
$ svn add foo
$ svn commit -m "test"
Adding foo
Revision X sent.
$ rmdir foo
$ svn st
! foo
$ svn delete foo
D foo
And finally this command fails:
$ svn commit foo -m "fail"
svn: entry "foo" has no URL
21 matches
Mail list logo
