On Wed, 28 Feb 2018 03:21:01 +, NOCERA, ANDY wrote:
> My cert is not valid at this point, I had turned off ssl and had the same
> error. I wasn???t sure how to get beyond the 301 on a curl
You ask for .../asgard, and get redirected to .../asgard/ (note the slash at
the end). Try that.
And
On Thu, 18 Jan 2018 17:38:04 +, Bo Berglund wrote:
...
> When I check out these projects from SVN the Swedish characters in the
> names are now replaced by a series of high characters (hex view):
>
> Å = C3 90 C2 9F
This is strange - it superficially looks like a double ISO-8859-1 to
utf8 con
On Sun, 17 Dec 2017 01:22:06 +, Branko ??ibej wrote:
...
> The /path/ of the file implies which branch or tag it belongs to. There
> is no other information you need.
Oh yes, there is. Knowing which files are included in the tag
is fine (and a very basic property), but I'd also like to be
able
On Mon, 18 Dec 2017 00:35:29 +, Bo Berglund wrote:
...
> I have a hard time getting to understand this...
> Do you mean that using "trunk", "branches" and "tags" as directories
> is entirely voluntary?
Exactly.
> Does this also mean that files inside a
> tags/something directory can be modifi
On Thu, 20 Jul 2017 17:38:38 +, Nathan Hartman wrote:
...
> One myth that is not mentioned on that page is the famous, "But you can't
> work offline!" Being able to work "offline" is supposed to be the biggest
> selling point of a DVCS over a CVCS. Okay... I'm calling that a myth. First
> of al
On Fri, 23 Dec 2016 13:22:03 +, Olaf van der Spek wrote:
...
> > (modulo externals). Having .svn outside the worktree isn't
> > relevant for me; my gripe with .svn is that the pristine
> > copies aren't compressed and thus generate matches in
> > 'find | xargs grep' (in the nonexistence of 'svn
On Fri, 23 Dec 2016 09:30:45 +, Stefan Sperling wrote:
...
> Well, at the time the wc-ng effort was started, a centralized .svn was
> one of the design goals. That's why the DB schema is the way it is.
See, I thought, wc-ng was done, with the single .svn directory
(modulo externals). Having .s
On Thu, 22 Dec 2016 13:48:47 +, Stefan Sperling wrote:
...
> I think this idea is short-sighted. I can imagine this suggestion to cause
> major inconvenience if implemented.
I know of a VCS having done exactly this.
> Inevitably, an environment variable will point to a .svn directory of one
>
On Thu, 29 Sep 2016 14:58:44 +, Anton Shepelev wrote:
...
> Is there no protection against an oblivious users's
> losing a day's work merely because he forgot to up-
> date his working copy, which was obsolete beyond
> merging?
He will learn it, lucky eddie style.
If you plan doing mass
On Sat, 02 Jul 2016 13:52:05 +, Stefan Sperling wrote:
...
> And I agree that this argument is missing the point. It claims that because
> a merge may select just a subset of changes committed in a particular
> revision,
> drawing a "line" to indicate a merge commit would be misleading since n
On Wed, 27 Aug 2014 16:08:14 +, Zé wrote:
...
>
> I don't see your point. There's also a likelihood that those accidents
> can happen on a remote server.
The difference being that anybody can accidentally do a rm -rf on the
part after the file - anybody who can work with the repo.
In a ser
On Wed, 04 Jun 2014 15:50:35 +, James French wrote:
...
> The purpose of the repo in question is to store 3rd party distros. I've lost
> count of the times over the years that we've fallen foul of files not being
> checked in and then only finding out later.
Perhaps you shouldn't build relea
On Thu, 22 May 2014 20:08:15 +, David DL wrote:
...
> It's my understanding that if you want the process to integrate a new vendor
> drop to be sane, the update ideally should be expressed as a series of "svn
> actions" (add/update/etc.) so that history is maintained.
>
> The obvious optio
On Thu, 28 Nov 2013 10:58:08 +, Les Mikesell wrote:
...
> different people were working on the separate copies. What commit
> log message would ever be appropriate if you commit to both the trunk
> and branch through an upper level directory that ties them together?
svn commit -m 'just to co
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
On Fri, 11 Oct 2013 17:43:30 +, Branko ??ibej wrote:
...
> Of course, if someone used the U+2424 newline code point instead, then
> in the worst case, the whole file would be interpreted as a single line.
And SVN would be right, as U+2424 is 'SYMBOL FOR NEWLINE', which is
actually a printable
On Fri, 20 Sep 2013 05:57:04 +, Lorenz wrote:
...
> >Does that actually work again on big repositories?
> >It used not to, and just omit some.
>
> don't know, never tried it.
>
> But I can't remember anyone posting about a problem either
I definitely had the problem, but for obvious reason I
On Thu, 19 Sep 2013 08:36:19 +, Lorenz wrote:
...
> you can use:
>
> svn propget svn:externals -R repoURL
>
> to get all external definitions.
Does that actually work again on big repositories?
It used not to, and just omit some.
Andreas
--
"Totally trivial. Famous last words."
From
On Fri, 19 Jul 2013 09:44:05 +, Øyvind 'bolt' Hvidsten wrote:
...
> In the restricted network, the SOCKS proxy is dante, but as I mentioned,
> the same situation occurs with a simple ssh -D proxy.
You may want to run a simple local http proxy that itself can use
a SOCKS5 proxy to access the i
On Sat, 20 Jul 2013 11:50:06 +, Nico Kadel-Garcia wrote:
> On Sat, Jul 20, 2013 at 2:16 AM, Andreas Krey wrote:
...
> My experience is from specificity, not generality.
Me too. Only I'm just seeing a project where it takes months to
get all the support stuff working for the ne
On Thu, 18 Jul 2013 07:45:52 +, Nico Kadel-Garcia wrote:
...
> * When ready to migrate from the old source control, do a clean dump of the
> old system, and svn import into the new system into a branch, and make a
> locked *tag*. Do not *bother* with the old history.
I strongly disagree with t
On Tue, 09 Jul 2013 21:43:50 +, Stefan Sperling wrote:
...
> I think using UTF-8 by default would be a good choice today. But it
> certainly wasn't when the Subversion project was started years ago.
> And we cannot change the existing default behaviour now. That would
> create compatibility nig
On Tue, 09 Jul 2013 20:21:33 +, Branko ??ibej wrote:
...
> I posit that if the "native encoding" is supposed to be UTF-8, then it
> is an error to use LANG=C at all. Instead, one should use LANG=C.UTF-8.
No, using LANG etc. for the interface between svn and the disk mixes up
the setup for the
On Tue, 09 Jul 2013 16:26:40 +, Branko ??ibej wrote:
...
> Since we're on the topic, would you care to explain why translating
> files to the native encoding is "a rather stupid idea"?
Because LANG isn't "the native encoding", but, for the file system
the "naive encoding".
What encoding is us
On Tue, 09 Jul 2013 12:55:29 +, Michael Pruemm wrote:
...
> The difference is in the setting of the LANG environment variable.
> When set to "en_US.UTF-8", everything works as it should, but with
> LANG=C, the check-out always fails.
svn wants to convert file names in the repository to filenam
On Tue, 09 Jul 2013 09:52:22 +, Thorsten Schöning wrote:
...
> am Dienstag, 9. Juli 2013 um 07:31 schrieben Sie:
>
> > 9550 Files, half a GB wc size, 15 seconds.
>
> > You may want to use another file system?
>
> Or your hardware and connection to your repo with it's server etc. I
> vote for
On Mon, 08 Jul 2013 18:06:45 +, Naumenko, Roman wrote:
...
> For example, on one of the other servers it takes 12-13 min to checkout
> repo with ~17000 files, total size 1.2G (with average speed 2MB/s).
>
> Is it considered good, bad or total disaster in term of svn performance?
To me this l
On Mon, 08 Jul 2013 14:33:03 +, Andy Levy wrote:
> I just checked out 2400 files, about 1.7GB, and it took just over 19 minutes.
>
> Client I/O speed is a big factor (7200RPM hard drive w/ NTFS in my case).
9550 Files, half a GB wc size, 15 seconds.
You may want to use another file system?
On Fri, 14 Jun 2013 12:55:11 +, Andrew Reedick wrote:
...
> Back in my day, CC snapshot views were terrible/horrible/nearly_unusable.
> SVN workspaces are simply great. I doubt your users will complain once they
> start using them.
There is one thing that potentially can cause a *lot* of p
On Thu, 13 Jun 2013 21:57:17 +, Olivier Antoine wrote:
...
> I think that dynamic view is still a nice concept. Dynamic views is
> something that users like much, and they desespair when they have to
> migrate to snapshot views.
> You create your view, you have an (almost) real-time connection
On Thu, 13 Jun 2013 16:23:39 +, Les Mikesell wrote:
...
> > Revision numbers can be renumbered one day in the repository, so they cannot
> > be used in the SCM process, am I wrong ?
>
> No, revisions can never be renumbered in an existing repository. It
> is possible to dump the repository a
On Tue, 04 Jun 2013 14:09:35 +, Saffer, Simon wrote:
...
>
> A
> B
>
>some change
>
>some change
>
> C
> D
>
> We get no merge conflict, but the text is copied twice into the file on trunk.
So, you add one line on trunk, and a different line (and different
whitespace miea
On Wed, 22 May 2013 19:33:33 +, David Chapman wrote:
...
>
> Usually only the build system (or developers trying to fix a specific
> bug) will check out a tag. Developers modifying code would not check
> out tags.
Unless they are using externals. Letting external point to a non-tag
thing i
On Tue, 21 May 2013 21:55:51 +, Jeffrey Walton wrote:
...
> I only need four or five basic commands -
> checkout,
git clone $repo
> update,
git pull --rebase (after committing your own stuff)
> commit,
git commit -a && git push (after a pull)
> add (files),
git add files
> remove (files
On Sun, 19 May 2013 09:20:31 +, Zé wrote:
...
> file system. What you are insistingly referring to as branches is
> nothing more than a copy of a particular subdirectory (i.e., the trunk)
> into another subdirectory (i.e., branches), which is nothing more than a
> plain recursive directory
On Sat, 18 May 2013 22:16:48 +, Johan Corveleyn wrote:
...
> Please be concrete, and give examples of what really bothers you as a
> user or an admin in your daily work. Saying that "branches are not
> first class", or "I don't like it that Subversion implements
> branches/tags by copying direc
On Sat, 18 May 2013 17:24:33 +, Zé wrote:
...
> Compared to how other SCM systems handle tags, subversion also doesn't
> have tags as a separate concept. Subversion provides a way to pinpoint
> each commit objectively and unambiguously by specifying specific
> revisions.
Not even that. You
On Sat, 18 May 2013 19:33:10 +, Thorsten Schöning wrote:
> Guten Tag Zé,
> am Samstag, 18. Mai 2013 um 18:24 schrieben Sie:
>
> > The only difference between subversion and other SCM systems
> > is that other systems offer support for labeling and adding useful info
> > to those revisions, whi
On Sat, 18 May 2013 19:33:10 +, Thorsten Schöning wrote:
...
> That's not an argument at all, because all one does in other SCMs is
> creating branches and tags. What you really should argue is what all
> devs think is common sense about branches and tags
You mean like 'I expect tags to be imm
On Wed, 15 May 2013 13:06:52 +, Andrew Reedick wrote:
...
> In the Future(tm), Subversion, IMHO, will need to treat branches (and tags)
> as first class objects because branches and tags are core concepts of modern
> version control systems.
So what? SVN decided to map them into the director
On Mon, 13 May 2013 18:35:35 +, Bob Archer wrote:
...
> Been a while since I have really got into the git internals, but I think each
> changeset has a SHA1 hash... if a changeset with that hash is already in a
> branch merging won't do anything... there will be nothing to merge.
> That said
On Mon, 13 May 2013 13:29:39 +, Les Mikesell wrote:
...
> ...What does git do if
> you try to double-merge a change?
You can't.
> Does it know about the previous
> merge by its changeset commit id, look at the contents that are
> already present, or just do it twice?
It doesn't have a no
On Mon, 13 May 2013 11:32:13 +, Les Mikesell wrote:
...
> Maybe it is just my misconception, but I've always thought of the
> difference between svn and git as being that svn conceptually tracks
> complete revisions although sometimes it might generate or store
> differences for some operations
On Wed, 27 Mar 2013 10:21:01 +, Niemann, Hartmut wrote:
...
> Is there any way to repair/refresh a pristine directory in subversion? Or is
> a fresh checkout the only option?
You could just do a fresh checkout and then untar your backup onto
that sandbox.
HOWEVER: You need to checkout the re
On Thu, 07 Feb 2013 23:00:33 +, Marius Gedminas wrote:
...
> The cron script runs svnsync every 5 minutes.
Do you make sure svnsync isn't started anew when the previous instance
hasn't terminated yet? (I don't know if that matters.)
Andreas
--
"Totally trivial. Famous last words."
From: Li
On Sat, 02 Feb 2013 11:51:15 +, Daniel Shahaf wrote:
> Matt Hargett wrote on Sat, Feb 02, 2013 at 02:04:06 +:
> > To parallel the additions of --include-externals to the 'commit' and 'ls'
> > commands, I would also like to propose adding the option to the 'diff'
> > command. I just tested l
On Thu, 20 Sep 2012 14:18:11 +, Thorsten Schöning wrote:
...
> I maybe misunderstand your argumentation but the only thing I read
> over and over again is: Use git, it's superior.
Well, it is. :-) [As I said, in my domain but I think not just in my
opinion.] But I was discussing why that meant
On Thu, 20 Sep 2012 14:27:20 +, Stefan Sperling wrote:
> On Thu, Sep 20, 2012 at 01:35:26PM +0200, Andreas Krey wrote:
> > and the availablility of anything that can serve git and svn
> > clients will basically make any more svn updates unneeded.
>
> To be frank, tha
On Thu, 20 Sep 2012 06:36:02 +, Nico Kadel-Garcia wrote:
...
>
> I think it's justified paranoia, due to concerns about "how are you
> ever going to keep this reliably in sync with upstream Subversion
> repository features" ?
Like, not at all? (Note: I'm not affiliated with either github
or s
On Thu, 20 Sep 2012 00:13:45 +, Nico Kadel-Garcia wrote:
> Java has its uses. Replacing a full-blown, fully implemented C++
> codebase where the maintainers, who also set the API's, are all
> working in C++ means entirely different models of file handling,
> memory management, and maintain
On Thu, 20 Sep 2012 00:13:45 +, Nico Kadel-Garcia wrote:
...
> Except, of course when it doesn't. The use of OS specific EOL, which
> git does not support, and subversion keywords like $Id$ and $Author$,
> which git does not support, would seem to me to be an adventure
> begging to happen.
Or
On Tue, 11 Sep 2012 13:11:08 +, John Maher wrote:
...
> I don't understand this statement at all. I'm talking about a simple
> wrapper.
Ok, I got that wrong. But exactly for those wrappers there is no point in
trying to do *everything* the CLI can do in the GUI as well. Streamline
the most im
On Tue, 11 Sep 2012 12:02:51 +, John Maher wrote:
...
> line can except take more time to do something. You're confusing the
> steps to design an application with the steps to design a wrapper.
You're confusing a single application with the whole command line
and *everything* it can invoke. I
On Sat, 04 Aug 2012 14:52:07 +, Nico Kadel-Garcia wrote:
...
> Maybe most users simply work in 7-bit ASCII character sets and avoid
> whitespace, punctuation, and Roman-characters as s matter of common
> practice for software stability?
Fun can be had with special characters on almost every pl
Hi everybody,
our sysdamins raised a question whether 'svnadmin dump' is safe to
run on a live repo (served via apache). The man page does not list a
requirement to stop other operations before dumping, but neither does
it go into any detail what happens if new revisions are created while
the dump
On Tue, 12 Jun 2012 12:26:34 +, Johan Corveleyn wrote:
...
> > - BUT I cannot update again, I have to cleanup first!
>
> This seems normal too. Before doing anything, 'svn update' will lock
> the working copy (to prevent any concurrent svn actions from messing
> with it while it's updating). I
On Tue, 05 Jun 2012 17:05:16 +, Bert Huijben wrote:
...
> > Can't rule that out. I did the final runs for that one in another WC,
> > but I may have ^C'ed this one, too. I mostly reported this because
> > of the 'externals, again' note in one of the reactions in the ^C thread,
> > so for now ->
On Tue, 05 Jun 2012 11:20:52 +, Stefan Sperling wrote:
...
> Can you reproduce this problem reliably, with a fresh repository and
> working copy?
I didn't even try; I never had anything like that beforehand.
> In an earlier thread[1], you were showing problems with externals and
> command can
On Tue, 05 Jun 2012 11:27:20 +, Stefan Sperling wrote:
...
> > Ok, this was transient and didn't reappear.
> >
> > Irritating, though. Do I still trust the WC?
>
> Is the WC on a local drive or a network drive of some kind?
Local. MacOS. I don't trust any network filesystem.
Andreas
--
"T
On Tue, 05 Jun 2012 07:46:17 +, Andreas Krey wrote:
...
> ---
> Fetching external item into 'module/tags/BUILD_module_V1.0.0/ant-scripts':
> External at revision 122958.
>
> svn: warning: W20: Error handling externals definition for
> 'module/tags/BUILD_
On Tue, 05 Jun 2012 07:46:17 +, Andreas Krey wrote:
> Hi,
>
> I'm momentarily getting strange errors handling some externals,
> like (on 'svn up'):
>
> ---
> Fetching external item into 'module/tags/BUILD_module_V1.0.0/ant-scripts':
> Extern
Hi,
I'm momentarily getting strange errors handling some externals,
like (on 'svn up'):
---
Fetching external item into 'module/tags/BUILD_module_V1.0.0/ant-scripts':
External at revision 122958.
svn: warning: W20: Error handling externals definition for
'module/tags/BUILD_module_V1.0.0/ant
On Fri, 01 Jun 2012 18:19:58 +, Michael P. Reilly wrote:
...
> What release of Subversion and what is your operating system?
1.6.6 and 1.7.4, behaving essentially similar. MacOS 10.5.8.
> Standard
> network has a timeout of about 120 seconds, but depending on the OS, the
> command may not be
On Sat, 02 Jun 2012 11:14:16 +, Stefan Sperling wrote:
...
> Some signals never have an immediate effect in Subversion.
> Subversion handles signals gracefully at defined points to ensure state
> is cleaned up properly.
Hanging more than a minute isn't exactly what I consider 'graceful'.
> Wh
Hi everybody,
is there already a bug on this? I can't always get the svn client to
stop using ^C. Mostly this seems to happen with slow network I/O, like,
for reproduction:
prompt> time svn checkout http://217.140.74.17/doesnotexist
^C^C^Csvn: OPTIONS of 'http://217.140.74.17/doesnotexist': c
On Tue, 01 May 2012 13:50:34 +, Thorsten Schöning wrote:
...
> Because Subversive seems to produce the same quality of content, just
> differently displayed.
But this kind of 'differently displayed' is quite valuable. Putting
commits in a list and narrowing the tree provides a lot more overvie
On Tue, 01 May 2012 12:31:58 +, Stanimir Stamenkov wrote:
...
> Andreas Krey suggested nice approach in his reply - convert the SVN
> repository to Git, then use that to display the history. I haven't
> tried the SVN to Git conversion -- this is basically the only thing
>
On Tue, 01 May 2012 02:14:16 +, Stanimir Stamenkov wrote:
> Is anyone aware of tools which (re)construct a DAG from Subversion
> repository history and display it pretty much like today's DVCSes?
'git svn' works for me.
Although you can easily create svn repos that have no good git
represen
On Thu, 26 Apr 2012 11:25:55 +, Andreas Krey wrote:
...
> > $ svn status | grep '^[A-Z]' | sed 's/^. \(.*\)$/\1/'
>
> $ svn status | sed -n 's/^[A-Z] \(.*\)$/\1/p' # From memory, untested
Oops (still from memory):
$ svn status | sed -n
On Thu, 26 Apr 2012 10:39:23 +, Stefan Sperling wrote:
...
> M alpha
> M epsilon/zeta
> $ svn status | grep '^[A-Z]' | sed 's/^. \(.*\)$/\1/'
$ svn status | sed -n 's/^[A-Z] \(.*\)$/\1/p' # From memory, untested
Andreas
--
"Totally trivial. Famous last words."
From:
On Thu, 15 Mar 2012 02:06:08 +, Daniel Shahaf wrote:
> Andreas Krey wrote on Wed, Mar 14, 2012 at 15:33:35 +0100:
...
> > But the real strange thing: I did only do a merge; not actually
> > edit any properties myself.
> >
>
> So? Propchanges are merged too.
Yes
On Wed, 14 Mar 2012 15:33:35 +, Andreas Krey wrote:
...
> Cannot accept non-LF line endings in 'svn:ignore' property
...
> Even worse: There are only 0a (LF) line endings in the ignore properties.
> No 0d (CR) in sight; at least in the output of 'svn pg svn:ignore&#
Hi,
the full glory:
svn: E175008: Commit failed (details follow):
svn: E175008: At least one property change failed; repository is unchanged
svn: E175002: Error setting property 'ignore':
Cannot accept non-LF line endings in 'svn:ignore' property
For one it would really helpful to know
On Wed, 14 Mar 2012 11:52:33 +, Simon Dean wrote:
...
> I use Rake and Gradle (migrated to Gradle from Maven). Rake is used for .NET
> codebases and Gradle for Java. It's very easy for files to slip through a
> "clean" task.
Actually the whole notion of a 'clean task' is misleading. Any
On Tue, 13 Mar 2012 21:14:04 +, David Weintraub wrote:
...
> So, it's possible for someone to write a Subversion client that does
> do a "clean up".
So, what you're saying is that, because it is possible to implement
'svn cleanup' on top of the svn client libs, the official svn client
won't ge
On Mon, 12 Mar 2012 10:03:16 +, Zachary Burnham wrote:
...
> By the way, is top or bottom posting proper for this list?
Inline, at the proper point, usually within a full quote. (And having
100k HTML for 2k plain text doesn't sound like a good idea either. The
raw line count of your mail made
On Sun, 11 Mar 2012 11:23:34 +, Les Mikesell wrote:
...
> That seems wrong or at least unnecessarily inconvenient for a CI
> setup.
You're a bit hung up on the 'CI' token. That isn't the only situation
where a 'svn cleanup' can be useful.
> And if you are doing it by hand, why not just delete
On Sat, 10 Mar 2012 10:47:55 +, Les Mikesell wrote:
...
> I'd argue that tools have no business removing any files they didn't
> create unless you name them explicitly. And that complicated things
> that you want a CI to automate should be scripted with the script
> managed in your VCS anyway
On Fri, 09 Mar 2012 11:53:47 +, Les Mikesell wrote:
...
> > So the CI would rely on another piece of software, SVN in this case, to
> > know what it has created in terms of files. Well, it doesn't seem right
> > to me.
>
> So how would you propose doing this across different VCS? I don't see
On Fri, 09 Mar 2012 14:10:39 +, Giulio Troccoli wrote:
...
> Sorry, but to me this has got nothing to do with Subversion.
'course it does. It knows which files are to be ignored, and thus
can be savely thrown away, and it does know which files are not
under version control, and thus should be
On Fri, 02 Mar 2012 14:54:38 +, Humm, Markus wrote:
...
> In my eyes nothing beats the simplicity and understandability of
> svn:externals with one single level deep relative paths
> to a directory above.
Exactly as long as you don't try to do
svn checkout http://your/soft/ware/trunk dir-
On Tue, 28 Feb 2012 11:55:38 +, Stephen Butler wrote:
...
> Or are you talking about something else? If so, make up a sample of
> the hard-to-read diff.
svn (up to 1.6.x) has the annoying habit of not doing property diffs
line-by-line but instead showing the whole externals block as changed.
On Thu, 23 Feb 2012 14:10:22 +, Stefan Sperling wrote:
...
> > svn cp --username=user --password= 'http://fromurl'
> > http://tourl/tags/builds/4.1.3.0_20120223.0 -m 'Nightly build tag created by
> > CI'
> > svn: File or directory 'tags/builds' is out of date; try updating
> > svn: re
On Thu, 23 Feb 2012 11:50:29 +, Torsten Krah wrote:
...
> In theory yes it would work to do the same thing again in post-commit -
> but pre-commit already did all the work before. Would be nice if there
> would be no need to parse and analyze things twice, may take time and
> resources dependin
On Wed, 15 Feb 2012 20:41:48 +, Stefan Sperling wrote:
> I don't know enough about SQlite to judge whether the DB will
> keep working at any frozen state a snapshot might create.
If it doesn't then it wouldn't be resilient to system crashes either,
and *that* wouldn't exactly be a recomme
On Wed, 11 Jan 2012 15:49:26 +, Steve Kelem wrote:
...
> I would like to run something like:
>
> svn propset svn:needs-lock '*' *.png *.jpg *.vsd
Crude hackaround:
for i in *.png *.jpg *.vsd; do svn propset svn:needs-lock '*' "$i"; done
That way, the errors won't keep the rest from workin
On Tue, 29 Nov 2011 15:57:28 +, Joshua McKinnon wrote:
...
> Oh the new working copy format is absolutely great. The point is only
> that the pristine files appear to build up over time, which seems new.
They do. For every changed file that comes to exist in the sandbox
a new pristine copy wil
On Sat, 19 Nov 2011 08:32:47 +, tsteven4 wrote:
...
> >configure: configure.in
> >autoconf
>
> Make has a hard time deciding if it needs to build configure. It ends
> up depending on the order the files were pulled during the "svn co"
> command. My experience on other projects is that
On Wed, 16 Nov 2011 17:40:55 +, Philip Martin wrote:
...
> It might be faster to run a recursive propget,
It might also be erroneous. I noticed in an 1.5/1.6 setup that
a recursive propget over a big subtree simply fails to yield *all*
relevant properties. That is, a
svn pg -R svn:externals
On Fri, 04 Nov 2011 10:06:32 +, Peter Schuck wrote:
> Hi,
>
> I would like to know if it is possible to ssh tunnel or somehow update a
> remote copy of my subversion tree. I've checked the FAQ and I know that
> you can just start up an remote shell on the machine, but the problem I
> have is a
On Fri, 28 Oct 2011 13:02:05 +, Flemming Frandsen wrote:
...
> The problem is that there are many more changes in the conflicted
> block than the diff suggested, iow: svn merge tried to add more lines
> than svn diff said it would.
That only looks like that because of the way merging is descri
On Fri, 28 Oct 2011 12:49:35 +, Flemming Frandsen wrote:
...
> This is not the only time I've seen the problem manifest, but the
> circumstances where similar, in the other case another developer was
> trying to merge a change from version-1 to version-2, he too got extra
> changes in his merge
On Tue, 25 Oct 2011 14:37:14 +, Markus Schaber wrote:
> Hi,
>
> As there seem to be a lot of users with broken pristine files[1], what about
> implementing a "repair pristine" command or option for cleanup which
> re-fetches those from the server?
May be a bit hard to justify as it is 'only
On Thu, 20 Oct 2011 21:27:38 +, Daniel Shahaf wrote:
> Andreas Krey wrote on Thu, Oct 20, 2011 at 20:38:58 +0200:
> > On Thu, 20 Oct 2011 19:26:06 +, Daniel Shahaf wrote:
> > > Have users always run 'svn cleanup' before they leave for the night on
> > &g
On Thu, 20 Oct 2011 19:26:06 +, Daniel Shahaf wrote:
...
> > > Upgrading a working copy that requires cleanup is not.
> >
> > How is a user supposed to know if his working copy requires cleanup?
>
> You'll get E155021.
Which would then mean that I need to reinstall 1.6, cleanup, and
go back
On Thu, 20 Oct 2011 09:43:58 +, Bob Archer wrote:
...
> You tried to upgrade a working copy with pending changes in it? Are you crazy?
I'm not aware that you can run two tortoises in parallel, which means
you have no chance of not upgrading an old WC if you want to update
it -> all of our WC h
On Wed, 19 Oct 2011 10:36:28 +, Philip Martin wrote:
> Andreas Krey writes:
...
> I think that is a zlib symbol. Subversion links some libraries against
> zlib but doesn't link executables to zlib directly, relying on the
> library to pull them in. If you build using
>
&
On Wed, 19 Oct 2011 11:37:25 +, Daniel Shahaf wrote:
...
> Adam, Andreas: when you say what passes/fails for you, please also
> mentino the environment. I've so far tested on 32bit Linux and I plan
> to test in a couple more environments once I rebuild trunk on them.
Do you build your test su
On Tue, 18 Oct 2011 23:21:12 +, Daniel Shahaf wrote:
> Andreas Krey wrote on Tue, Oct 18, 2011 at 23:15:29 +0200:
> > On Tue, 18 Oct 2011 22:12:47 +, Daniel Shahaf wrote:
> > ...
> > > - those foo.h file generated from foo.sql files are supposed to be
> > &g
On Tue, 18 Oct 2011 22:12:47 +, Daniel Shahaf wrote:
...
> - those foo.h file generated from foo.sql files are supposed to be
> pre-generated in the tarball
They are. Except that I copied over the tree, and the timestamps
afterwards were so that it tought it necessary to recreate. Ouch.
Ok,
1 - 100 of 167 matches
Mail list logo
