Re: auto-props syntax in file vs. property
I think the fix to svn_apply_autoprops.py should be something like below
(/subversion/trunk/contrib/client-side/svn_apply_autoprops.py)
If anyone with commit rights wants to fix it on the repo, feel free to use the
below, or improve it as necessary (my python knowledge is non-existing)
Index: svn_apply_autoprops.py
===
--- svn_apply_autoprops.py (revision 103617)
+++ svn_apply_autoprops.py (revision 103618)
@@ -101,7 +101,11 @@
# leading and trailing whitespce from the propery names and
# values.
props_list = []
-for prop in props.split(';'):
+# Since ;; is a separator within one property, we need to do
+# regex and use both negative lookahead and lookbehind to avoid
+# ever matching a more than one semicolon in the split
+semicolonpattern = re.compile("(? wrote:
Subject: Re: auto-props syntax in file vs. property
To: users@subversion.apache.org, "Daniel Shahaf"
Date: Wednesday, January 10, 2018, 8:25 AM
Hi Daniel,
thanks for the reply.
You're right that it seems to work when
I do "svn add" and with that config file, but when I do the
same with svn_apply_autoprops.py, it acts badly. I simply
forgot to check the regular add :)
So I get the problem when I do:
./svn_apply_autoprops.py
--config myconfig /path/to/workspace
Then it will set charset and mime-type
as two separate properties.
(and yes, it sets 3 properties overall,
I just meant that the mime-type got split into two)
I guess there's something in the parser
in svn_apply_autoprops that is misbehaving rather than svn
itself. A quick look in that file shows this line:
for prop in
props.split(';'):
Which I suspect is the root cause of
the issue, although I haven't verified it yet. I guess I
need to figure out some python basics and see if I can
ugly-hack that to work for double semicolons.
/Chris
On Tue, 1/9/18, Daniel Shahaf
wrote:
Subject: Re: auto-props syntax in file
vs. property
To: users@subversion.apache.org
Date: Tuesday, January 9, 2018, 5:05
PM
Chris wrote on Tue, 09 Jan 2018
15:15 +:
> When setting
svn:auto-props, it seems I can do
this:
>
> *.java =
svn:mime-type=text/java;;charset=iso-8859-1;svn:eol-style=LF
>
> That is, use ;; as
an escape between the "parameters" for
file type
and
> charset. Adding a java-file and
doing propget gives this:
>
text/java;charset=iso-8859-1
> Which
seems to be correct. Right?
Yes.
>
Using the exact same line in
~/.subversion/config seems to
see "charset"
> as a separate
property from "mime-type" and set two
different
properties
> on the file with
"charset" having no meaning.
I can't reproduce this. With that
line in
~/.subversion/config I get:
[[[
% svn add foo.java
A foo.java
% svn pl
-v foo.java
Properties on
'foo.java':
svn:eol-style
native
svn:mime-type
text/java;charset=iso-8859-1
]]]
(The value
'native' was inherited from
svn:auto-props in the
working
copy I was testing in.)
Also, does it really set *two*
properties on the file? Not
three?
"svn:mime-type",
"charset",
"svn:eol-style"?
What client and version do you use?
Cheers,
Daniel
File timestamps?
I notice that if I do a svn co on a project all files will get a timestamp as of the co time. But if I do a svn export of the same project the files retain their original timestamps (the time of commit of the file). Is there some argument that can be applied to svn co to tell it to keep the timestamps? -- Bo Berglund Developer in Sweden
Re: File timestamps?
On Wed, Jan 10, 2018 at 1:02 PM, Bo Berglund wrote: > I notice that if I do a svn co on a project all files will get a > timestamp as of the co time. > But if I do a svn export of the same project the files retain their > original timestamps (the time of commit of the file). > Is there some argument that can be applied to svn co to tell it to > keep the timestamps? There is a client-side configuration option for that: use-commit-times=true. See the "use-commit-times" option in this section of the book: http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts.config -- Johan
Re: File timestamps?
On Wed, 10 Jan 2018 13:08:14 +0100, Johan Corveleyn wrote: >On Wed, Jan 10, 2018 at 1:02 PM, Bo Berglund wrote: >> Is there some argument that can be applied to svn co to tell it to >> keep the timestamps? > >There is a client-side configuration option for that: use-commit-times=true. >See the "use-commit-times" option in this section of the book: >http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts.config Thanks, I enabled the setting in my Subversion\config file and did a new checkout of a module. Now I am getting the repo timestamps! -- Bo Berglund Developer in Sweden
Re: Question regarding reverse merge of added file
On Mon, Jan 8, 2018 at 2:24 PM, Max Bernhardt wrote: > Hi all, > > We've just upgraded our subversion server from 1.4.6 to 1.9.7 and now I'm > getting a strange merge conflict, when I'm trying to do a reverse merge on a > baseline (trunk). > > The situation is as follows: > /project/branches/it/33931/db/data_update.sql <- Branch created from > /project/branches/releases/23 in r374471, File added in revision r374494 > /project/branches/releases/23/db/data_update.sql <- File added via merge > of r374471- 374494 of /project/branches/it/33931 > > Now I've found out that this merge was wrong and want to reverse it. I tried > to run the reverse merge on the baseline: > > svn log -v db/data_update.sql > r378753 | maxbernhardt | 2018-01-04 15:06:11 +0100 (Do, 04 Jan 2018) > | 7 lines > Changed paths: > M /project/branches/releases/23/db > A / project/branches/releases/23/db/data_upgrade.sql (from > /project/branches/it/33931/db/data_upgrade.sql:374494) > Prodbuild: Committing svn://pbsvn/project/branches/it/33931 > > svn info > Path: . > Working Copy Root Path: /home/cmi/wc/project/23 > URL: svn://pbsvn/project/branches/releases/23 > Repository Root: svn://pbsvn Revision: 379041 > > svn merge -c-374494 svn://pbsvn/project/branches/releases/23 . > --- Reverse-merging r374494 into '.': > C update_data.sql > --- Recording mergeinfo for reverse merge of r374494 into '.': > G . >Summary of conflicts: >Tree conflicts: 1 > >svn st >M db > C db/data_update.sql > > local edit, incoming delete upon merge >Summary of conflicts: >Tree conflicts: 1 > > svn diff db/data_update.sql > > > Since a tree conflict can only be resolved to the state of the working copy > and the file still exists in the working copy of the baseline, > how can I do a reverse merge to remove the file from the baseline without > creating a tree conflict ? > > I know, I can remove the file manually by running "svn rm", but if there are > more complicated merges in the future, > this can only be seen as a workaround. > > Can you please explicitly cc me, because I'm not subscribed to mailing list > ? Hm, that's pretty strange. I don't know where the "local edit" comes from either. Is your client also version 1.9.7? Regardless of the underlying cause of the spurious "local edit", the upcoming version 1.10 should improve this situation by offering much more powerful "tree conflict resolution" options (some of which will be executed automatically). See [1]. Now, in your case the easiest way to resolve this conflict manually is running "svn revert db/data_update.sql" in your conflicted working copy. That will throw away the (spurious) local modification, and by that automatically resolve the tree conflict. [1] http://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver -- Johan
Re: auto-props syntax in file vs. property
Chris wrote on Wed, 10 Jan 2018 08:26 +:
> I think the fix to svn_apply_autoprops.py should be something like below
> (/subversion/trunk/contrib/client-side/svn_apply_autoprops.py)
> If anyone with commit rights wants to fix it on the repo, feel free to
> use the below, or improve it as necessary (my python knowledge is non-
> existing)
>
> Index: svn_apply_autoprops.py
> ===
> --- svn_apply_autoprops.py (revision 103617)
> +++ svn_apply_autoprops.py (revision 103618)
> @@ -101,7 +101,11 @@
> # leading and trailing whitespce from the propery names and
> # values.
> props_list = []
> -for prop in props.split(';'):
> +# Since ;; is a separator within one property, we need to do
> +# regex and use both negative lookahead and lookbehind to avoid
> +# ever matching a more than one semicolon in the split
> +semicolonpattern = re.compile("(? +for prop in re.split(semicolonpattern, props):
That's clever, but it will misparse sequences of three or more semicolons in a
row, such as
*.foo = key=val;;with;;semicolons;;;anotherkey=anotherval
Daniel
