Hi Team,
Iam facing an issue while setting up subversion repository on Solaris 5.10
PFB the steps followed.
1. Execute ‘svnadmin create /data/installs/repo’
Give 777 permissions to the files and folders in /data/installs/repo
2. Go to the folder /data/installs/repo/conf
Modify svn
> I don't think I did fully understand the interaction between your
> build system and your devs, as normally build systems like Jenkins,
> Hudson etc. run on a separate server fully automated and per default
> just don't commit anything, therefore it's very unimportant if the
> working copy they a
Yes, it was the "svn:log" property on the revision (as opposed to the node)
which was causing the issue. Was able to modify it with the "propset"
command and it has allowed svnsync to continue the sync.
So, the file to be patched is:
http://svn.apache.org/repos/asf/subversion/trunk/subversion/svns
IIRC svnsync would only complain about revisions add or modify an
svn:log property --- other changes to files having that property (even
with a bad value) should sync errorlessly. See validate_revision() in
subversion/libsvn_repos/fs-wrap.c
Anyway. I suggest you figure out a way to exclude "svn:
Hmmm... yes indeed. This does seem to be the case, as the same developer
committed the same file, with the same log message in another location, and
this time the dump/load is not working.
Even though the load doesn't throw any errors, when continuing with the
svnsync after loading, it starts comp
Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:58:01 +1300:
> Checked it by examining the contents of the dump file (cat [dumpfile]).
> Where I expected to see:
>
> client?\146s
>
Wrong expectation, dump files never include this syntax.
> I instead got:
>
> client?s
>
This doesn't say whether
Checked it by examining the contents of the dump file (cat [dumpfile]).
Where I expected to see:
client?\146s
I instead got:
client?s
Then, after copying it over to the slave and running "load", without the
"--bypass-prop-validation" flag, the dump is loaded without any errors
complaining about
Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300:
> Thanks for that. Using svnadmin "dump" and then "load" worked.
>
> I didn't even have to pass the "--bypass-prop-validation" option to the
> load command, as it seems the non-UTF8 symbols were converted to a "?" by
> the dump command.
Ho
Thanks for that. Using svnadmin "dump" and then "load" worked.
I didn't even have to pass the "--bypass-prop-validation" option to the
load command, as it seems the non-UTF8 symbols were converted to a "?" by
the dump command.
--
Srdan Dukic
On 30 October 2012 15:57, Daniel Shahaf wrote:
> Sr
Srdan Dukic wrote on Tue, Oct 30, 2012 at 15:20:24 +1300:
> Hi,
>
> I'm trying to setup an subversion replication between two servers (both
> running version 1.6.11). When I try to replicate the data, I get the
> following error in the logs:
...
> But still no luck. Can anyone tell me how to modif
Srdan Dukic wrote on Tue, Oct 30, 2012 at 15:20:24 +1300:
> But still no luck. Can anyone tell me how to modify the "svn:log" property
> on the file itself, as opposed to the revision property? Has anyone seen
> this issue before?
>
You need to use some tool that modifies history. (Which tool?
Hi,
I'm trying to setup an subversion replication between two servers (both
running version 1.6.11). When I try to replicate the data, I get the
following error in the logs:
Cannot accept 'svn:log' property because it is not encoded in UTF-8 [500,
#125005]
I've figured out which property it is,
Hello,
We did our first release in SVN today. I used the copy command (shown
below) to copy from /trunk to /tag. Since not everything in /trunk was
needed for this release, I had to specify the directories which were
needed.
Q1. Is this the normal/correct way of doing things? For the new
Guten Tag Vitor Barata,
am Montag, 29. Oktober 2012 um 16:56 schrieben Sie:
> So, I would like to know if anyone has a better idea, and/or
> if anyone agrees that a local .svnignore file (or an extra unversioned
> svn:ignore property) has a good use after all.
I don't think I did fully understand
> I have searched for this issue in several places, but none of the feature
> requesters presented a scenario like mine, and the overall conclusion was that
> the svn:ignore property was sufficient. However, I stand by the opinion that a
> local .svnignore file is also necessary (or some kind o
Hello all,
I have searched for this issue in several places, but none of the
feature requesters presented a scenario like mine, and the overall
conclusion was that the svn:ignore property was sufficient. However, I
stand by the opinion that a local .svnignore file is also necessary
(or some ki
16 matches
Mail list logo
