On Fri, 24 Jul 2020 at 07:06, Daniel Shahaf wrote:
>
> Daniel Sahlberg wrote on Fri, 24 Jul 2020 05:53 +00:00:
> > Den fre 24 juli 2020 01:46sebb skrev:
> > > I am suggesting that 'add' functionality could be added to svnmucc itself.
> > > This would make
Daniel Sahlberg wrote on Fri, 24 Jul 2020 05:53 +00:00:
> Den fre 24 juli 2020 01:46sebb skrev:
> > I am suggesting that 'add' functionality could be added to svnmucc itself.
> > This would make it more versatile, especially for use in shell scripts.
>
> Unles
Den fre 24 juli 2020 01:46sebb skrev:
> I am suggesting that 'add' functionality could be added to svnmucc itself.
> This would make it more versatile, especially for use in shell scripts.
>
Unless I'm mistaken, add is a purely local action within a working copy.
And t
n add a new file or update an existing one.
> > > >
> > > > As part of a batch update it may be necessary to ensure that a
> > > > particular file will be created and not updated - or vice versa.
> > > > That is currently not at all easy to do, which is a
sebb wrote on Thu, 23 Jul 2020 11:18 +0100:
> On Thu, 23 Jul 2020 at 01:17, Daniel Shahaf wrote:
> > You can either parse stderr despite this complication, or use the
> > API directly, in which case you'll sidestep this complication entirely
> > (you'll get just one integer, rather than two).
>
pdate it may be necessary to ensure that a
> > > particular file will be created and not updated - or vice versa.
> > > That is currently not at all easy to do, which is a shame as svnmucc
> > > is otherwise very useful for writing atomic updates that are not
> >
e created and not updated - or vice versa.
> > That is currently not at all easy to do, which is a shame as svnmucc
> > is otherwise very useful for writing atomic updates that are not
> > possible with the svn client.
>
> What can svnmucc(1) do that svn(1) can't?
Atomi
ese error codes defined?
> > > > I could not find any reference to them in the documentation.
> > >
> > > If you mean where in the source code:
> > >
> > > subversion/include/svn_error_codes.h
> > > which is included by subversion/inclu
mean where in the source code:
> >
> > subversion/include/svn_error_codes.h
> > which is included by subversion/include/svn_error.h, which is further
> > included by subversion/svnmucc/svnmucc.c.
> >
> > Hope that helps,
>
> Thanks, but not really.
>
to do, which is a shame as svnmucc
> is otherwise very useful for writing atomic updates that are not
> possible with the svn client.
What can svnmucc(1) do that svn(1) can't?
> Would there be any support for extending svnmucc to add these operations?
> Either as options to pu
The SVN put command can add a new file or update an existing one.
As part of a batch update it may be necessary to ensure that a
particular file will be created and not updated - or vice versa.
That is currently not at all easy to do, which is a shame as svnmucc
is otherwise very useful for
; > to convert numbers to symbolic names.)
> >
> > Where are these error codes defined?
> > I could not find any reference to them in the documentation.
>
> If you mean where in the source code:
>
> subversion/include/svn_error_codes.h
> which is included by subve
codes defined?
> I could not find any reference to them in the documentation.
If you mean where in the source code:
subversion/include/svn_error_codes.h
which is included by subversion/include/svn_error.h, which is further
included by subversion/svnmucc/svnmucc.c.
Hope that helps,
Nathan
On Sun, 12 Jul 2020 at 18:13, Daniel Shahaf wrote:
>
> sebb wrote on Sun, 12 Jul 2020 16:55 +0100:
> > On Sun, 12 Jul 2020 at 15:26, Daniel Shahaf wrote:
> > >
> > > sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> > > > When I first started
sebb wrote on Sun, 12 Jul 2020 16:55 +0100:
> On Sun, 12 Jul 2020 at 15:26, Daniel Shahaf wrote:
> >
> > sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> > > When I first started using svnmucc, it used to be the case that
> > > svnmucc 'put' --revis
On Sun, 12 Jul 2020 at 15:26, Daniel Shahaf wrote:
>
> sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> > When I first started using svnmucc, it used to be the case that
> > svnmucc 'put' --revision 0 would fail if the target file already
> > existed. This no long
sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> When I first started using svnmucc, it used to be the case that
> svnmucc 'put' --revision 0 would fail if the target file already
> existed. This no longer happens.
>
Is the file-to-be's parent directory the root directo
When I first started using svnmucc, it used to be the case that
svnmucc 'put' --revision 0 would fail if the target file already
existed. This no longer happens.
The previous behaviour was very useful, so are there any plans to reinstate it?
I don't think there is a straigh
sebb wrote on Tue, 07 Jul 2020 12:55 +0100:
> Is there any restriction on svnmucc targets which can appear in a batch
> script?
>
> I assume that all targets must be in the same repository, but are
> there any further restrictions, e.g. must they have the same initial
> r
Is there any restriction on svnmucc targets which can appear in a batch script?
I assume that all targets must be in the same repository, but are
there any further restrictions, e.g. must they have the same initial
root directory path?
I ask this because I am getting the following:
svnmucc
Nevermind.
Seeing that /usr/local/lib was included in the compile line as "rpath", I tried
moving all existing libsvn_* files from /usr/local/lib to an "old_1.11"
directory (they came from the 1.11 compilation)
After that, "make" just went fine.
Regards,
Juanga
Hello,
Build box is an Ubuntu 18.04 where only standard system updates are applied.
Built svn 1.11.0 from sources with no problems, now trying to build the latest
1.12.2 is throwing the following error.
[...]
cd subversion/svnmucc && /bin/bash "/usr/local/src/subversion-1
Sam Ruby wrote on Mon, 05 Jun 2017 14:24 -0400:
> On 06/05/2017 02:10 PM, Daniel Shahaf wrote:
> > Sam Ruby wrote on Mon, 05 Jun 2017 10:08 -0400:
> >> When I moved whimsy from Ubuntu 14.04 (svn 1.8.8) to Ubuntu 16.04 (svn
> >> 1.9.3), svnmucc commands started failing
On 06/05/2017 02:10 PM, Daniel Shahaf wrote:
Sam Ruby wrote on Mon, 05 Jun 2017 10:08 -0400:
When I moved whimsy from Ubuntu 14.04 (svn 1.8.8) to Ubuntu 16.04 (svn
1.9.3), svnmucc commands started failing for me:
$ svnmucc --revision 0 --message 'test data, please ignore' -- p
Sam Ruby wrote on Mon, 05 Jun 2017 10:08 -0400:
> When I moved whimsy from Ubuntu 14.04 (svn 1.8.8) to Ubuntu 16.04 (svn
> 1.9.3), svnmucc commands started failing for me:
>
> $ svnmucc --revision 0 --message 'test data, please ignore' -- put -
> https://svn.apache.org
When I moved whimsy from Ubuntu 14.04 (svn 1.8.8) to Ubuntu 16.04 (svn
1.9.3), svnmucc commands started failing for me:
$ svnmucc --revision 0 --message 'test data, please ignore' -- put -
https://svn.apache.org/repos/private/financials/Bills/paid/test < test
svnmucc: E160016: Ca
Thank you very much for the speedy change!
On Fri, May 2, 2014 at 10:54 PM, Ben Reser wrote:
> On 5/2/14, 3:24 PM, Dan Ellis wrote:
> > svnmucc currently only supports linefeed (LF, \n) line endings and
> complains
> > about window's style carriage return, line
On 5/2/14, 3:24 PM, Dan Ellis wrote:
> svnmucc currently only supports linefeed (LF, \n) line endings and complains
> about window's style carriage return, linefeed (CRLFs, \r\n) with:
> Error: svnmucc: E125005: Cannot accept non-LF line endings in 'svn:log'
> propert
Hi,
svnmucc currently only supports linefeed (LF, \n) line endings and
complains about window's style carriage return, linefeed (CRLFs, \r\n) with:
Error: svnmucc: E125005: Cannot accept non-LF line endings in 'svn:log'
property
This is inconsistent with the svn command line that
> Quoting is a solved problem, including quoting quotes.
Bwa-ha-ha-ha!. Hee. Giggle, Snort. Oh, dear lord, that one deserved a
"coffee and cats" warning. The handling of syntactically significant
characters, such as quotes, slashes, single quotes, and spaces is a
very common cross-platform proble
filesystems also
> allow. Besides, hilarity also ensues there when a file happens to be named
> 'rm’.
svnmucc handles arbitrary long command line arguments with spaces if they are
quoted. This is in regards to the -X command line option.
Blair
On Mon, 18 Nov 2013 07:11:40 +, Nico Kadel-Garcia wrote:
> Brother, unweaving the quotes is its own problem. You see, most
> filesystems allow single quotes and double quotes in the filenames
> themselves. Hilarity will ensue.
Quoting is a solved problem, including quoting quotes.
Using newli
> -Original Message-
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> Sent: Monday, November 18, 2013 7:12 AM
> To: Vladislav Javadov
> Cc: Blair Zajac; Andreas Mohr; Geoff Rowell; users@subversion.apache.org
> Subject: Re: svnmucc
>
> Brother, unweavi
Brother, unweaving the quotes is its own problem. You see, most
filesystems allow single quotes and double quotes in the filenames
themselves. Hilarity will ensue.
On Sun, Nov 17, 2013 at 4:19 AM, Vladislav Javadov wrote:
> BZ> The reason to support this syntax with command and arg on separate li
BZ> The reason to support this syntax with command and arg on separate lines
BZ> is to support files with whitespaces in the names
But what about quotes? Most OSes and programs accept quoted file names
containing spaces. Single-line commands are more readable, IMHO.
--
WBR,
Vladislav Javadov
On 11/16/13 8:38 AM, Blair Zajac wrote:
> The reason to support this syntax with command and arg on separate lines is to
> support files with whitespaces in the names, which wouldn't be possible wit
> the
> syntax of command and arg on a single line.
Yet another thing to add to the list of code t
separate line:
rm
programs/develop/fasm/tags
rm
programs/games/mine/tags
rm
programs/games/snake/tags
So, does that mean that svnmucc has single-arg support only?
Cause given this example, on the syntax side there's nothing
that would indicate that a new command is following,
rather than further op
grams/games/mine/tags
>>> rm programs/games/snake/tags
>>
>> Each command argument must be on a separate line:
>>
>> rm
>> programs/develop/fasm/tags
>> rm
>> programs/games/mine/tags
>> rm
>> programs/games/snake/tags
>
> So, does that
ent must be on a separate line:
>
> rm
> programs/develop/fasm/tags
> rm
> programs/games/mine/tags
> rm
> programs/games/snake/tags
So, does that mean that svnmucc has single-arg support only?
Cause given this example, on the syntax side there's nothing
that would indicate th
> On Nov 16, 2013, at 2:10 AM, Vladislav Javadov wrote:
>
> rm programs/develop/fasm/tags
> rm programs/games/mine/tags
> rm programs/games/snake/tags
Each command argument must be on a separate line:
rm
programs/develop/fasm/tags
rm
programs/games/mine/tags
rm
programs/games/snake/tags
- Geo
Hi,
My svnmucc 1.8.4 can't work with commands from a file, like these (saved
as 'normalize.mucc'):
rm programs/develop/fasm/tags
rm programs/games/mine/tags
rm programs/games/snake/tags
I try execute them via svnmucc:
svnmucc -U file:///X:/SVN/Kolibri.com -X normalize.mucc -m
Hi,
I've hit the following assertion in svnmucc:
svnmucc: subversion/libsvn_subr/dirent_uri.c:1373:
svn_uri_get_longest_ancestor: Assertion `svn_uri_is_canonical(uri1, ((void
*)0))' failed.
Aborted (core dumped)
The assertion was triggered when svnmucc was supplied with a script
test -n "$$SVN_SVNMUCC_IS_SVNSYITF" && \
>> ln -sf svnmucc$(EXEEXT) $(DESTDIR)$(bindir)/svnsyitf$(EXEEXT); \
>> if test "$(DESTDIR)$(bindir)" != "$(DESTDIR)$(toolsdir)"; then \
>> ln -sf $(DESTDIR)$(bindir)/svnmucc$(EXEEXT)
>> $(DESTDIR)$(
Nico Kadel-Garcia writes:
> # Compatibility symlink.
> # This runs after the target of the same name in build-outputs.mk.
> INSTALL_EXTRA_TOOLS=\
> $(MKDIR) $(DESTDIR)$(bindir); \
> test -n "$$SVN_SVNMUCC_IS_SVNSYITF" && \
> ln -sf svnmucc$(EXEEXT)
KDIR) $(DESTDIR)$(bindir); \
test -n "$$SVN_SVNMUCC_IS_SVNSYITF" && \
ln -sf svnmucc$(EXEEXT) $(DESTDIR)$(bindir)/svnsyitf$(EXEEXT); \
if test "$(DESTDIR)$(bindir)" != "$(DESTDIR)$(toolsdir)"; then \
ln -sf $(DESTDIR)$(bindir)/svnmucc$(EXEEXT)
$(DESTDIR
lso, svn propedit is for editing a single property of a single file or
directory. Since you want to edit properties of multiple files, svn propedit is
not going to work.
> Anyway thx for your idea but it doesn't really work the way I need it.
>
> I tested it using the svnmucc --e
u Feb 1 03:55:02 -0700 2007
It's the only hint I found to figure this out
Anyway thx for your idea but it doesn't really work the way I need it.
I tested it using the svnmucc --extra-arg FILE with following results :
1. FILE containing one operation per line
e.g. &
perty for every file in a certain
>directory(recursivly) using
>an url. Something like
>
>svn propedit -R PROPNAME PROPVAL URL
I think you meant propset
but anyhow svn prop* for versioned properties only work in on a
working copy.
the remote version only works for revision properties
tory(recursivly) using
an url. Something like
svn propedit -R PROPNAME PROPVAL URL
or
svnmucc propset PROPNAME PROPVAL -R URL
My problem is that propedit doesn't support recursivly setting of
properties and svnmucc gives an error( 'file already exists') when been
used on a file
### I set up a repository like this (this is the contents of the extra
args file specified by svnmucc -X):
mkdir
file:///C:/Temp/repo/trunk
mkdir
file:///C:/Temp/repo/trunk/test
put
file.v1.txt
file:///C:/Temp/repo/trunk/test/file.txt
mkdir
file:///C:/Temp/repo/tags
mkdir
file:///C:/Temp/repo
50 matches
Mail list logo
