Re: E130003: The XML response contains invalid XML - svn co and log issue on some repos using https/http

[Andreas Krey]

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.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: File and folder names corrupted when importing from CVS using cvs2svn

[Andreas Krey]

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 conversion, but it isn't. Å is C5 in 8859-1 (and in Windows Latin
1), and that is represented as c3 85 in utf8, and doing the conversion
twice yields c3 83 c2 85 which looks similar to yours, but isn't the same.

Doing that in reverse C3 90 C2 9F goes back to D0 9F which is the code
point 41F (CYRILLIC CAPITAL LETTER PE). Strange.

> What could I do to fix this?
> (And please note that the new repository is in use so there are a
> number of commits done since the migration...)

Standard SVN answer 'you should have...', in this case '...tested this
aspect before'.

Now I guess your best bet is to rename these files to the proper
thing (or remove them, as they are apparently not needed. :-) Old
history will look broken (but as nobody immediately had errors
with those trees perhaps that doesn't matter either).

svndumping, filtering and reloading may fix the file names for
all revisions, but I have no idea how the client sandboxes
will react to that.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: How to discover which files are tagged or branced in a hook script?

[Andreas Krey]

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 to find out

- which revision of the source tree the tag was taken of,

- which subtree it was taken of,

- and from the other end: which is the last tag
  taken from a specific subtree.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: How to discover which files are tagged or branced in a hook script?

[Andreas Krey]

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 modified and committed, thus changing
> the content of the tag?

Exactly. Since svn doesn't even know the concept of a 'tag' and its
preferred writeonce property, accidentally doing an 'svn cp trunk tags/1.0'
twice has interesting consequences.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: svn vs. git

[Andreas Krey]

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 all, there is nothing inherent to Subversion that "prevents" you from
> working offline. You can work, you just can't do server side operations.

In other words, you have a versioning system that you can't use offline,
except for local diffs.

> Is that such a big deal?

The big deal is a slightly different point. Making commit 'offline'
not only allows me to make commits while in the middle of nowhere
(and here in germany this easily includes trains).

It also allows me to make commits for a repo that I don't have
commit privileges for - I can commit my work in a meaningful way,
and later convince one of the official committers to pull these.

This also means that I can't maintain a patched version of
svn (or anything in an svn repo) without having commit
privilege to the source repo, or having to do the
vendor branch dance (with in itself is unnecessarily
annoying in svn).

> And if it is, do you mean to tell me that in this day
> and age of cloud services and IoT, where every single thing you do requires
> Internet access, that you're ever really "offline" for long enough that it
> matters?

It also makes a difference in speed - git log usually outputs data
faster than anybody can open an SSL connection in edge land.

...

> And even if you are planning to spend a year alone on a deserted
> island, nothing stops you from doing "svnadmin create" on your local
> computer and making as many commits as you want.

You know that that is a straw man. There is no in-svn way to
reconcile that with another repo, and also I don't want to
start on an empty repo, but, say, on the current svn trunk.

> But that doesn't make
> sense, because the longer you work in isolation, the less likely it is that
> your work will merge cleanly when you get back.

That is also orthogonal. Being offline does not mean that other people
work in the same repo, let alone area of a product. Also, the alternative,
namely working on trunk and do frequent updates, is worse in comparison,
because then you end up in conflicts in you sandbox, and have no way
of backing out and trying again later.

> Even the smartest and
> greatest DVCS in the world can't solve that problem.

Neither can non-distributed systems. The question is how long
you let work diverge, not where you do it.

> Subversion is a very good system. It doesn't get the credit it deserves,

Please. git managed to be faster in providing actually working
(i.e. tracked) merges than subversion, and then there was
the --reintegrate debacle that took another five years to
sort out.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: environment variable for location of the .svn directory ?

[Andreas Krey]

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 grep').
> 
> Don't find or grep have options to ignore dot / hidden files?

Sure they have. But you'd need to teach a dozen tools
this trick instead of letting one place hide it better.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: environment variable for location of the .svn directory ?

[Andreas Krey]

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 .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 grep').

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: environment variable for location of the .svn directory ?

[Andreas Krey]

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
> working copy but the current working directory will be part of a different
> working copy. Environment variables are useful for global system settings.

Or for use within scripts to communicate with things they invoke indirectly.
We use this productively because you cannot easily just have .vcs inside a
clearcase view or a temporary tree, so we keep it outside.

> Since each .svn dir lives in a separate working copy its path is not a
> global system setting.

A safer alternative would be to look, when in /home/ak/some/wc, for

  /home/ak/some/wc/.svn
  /home/ak/some/.svn.wc
  /home/ak/.svn.some.wc
  /home/.svn.ak.some.wc
  /.svn.home.ak.some.wc

or with an envvar SVNDIRS=/home/ak/svndirs

  /home/ak/some/wc/.svn
  /home/ak/svndirs/.svn.home/ak/some.wc

> I think the use case described would be much better served by implementing
> support for a shared .svn dir located e.g. in the user's home directory which
> can then be shared by multiple working copies.

This, incidentallly, is also *much* more complex to implement, beginning
with the problem that you can no longer just throw away a working copy
and its .svn directory, and ending with two users accessing a WC that
will now look into two different places for the .svn dir.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Implementing the Lock->Edit->Unlock cycle

[Andreas Krey]

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 massive work in a module, you
need to talk to the other people working in the
same module anyway, as they would be annoyed if
you locked the file, and they can't do planned work.

Ideally the other people do their commits in small
increments as well, and you could go and try to
merge their work to see if that works or starts
to fall apart. (Even more ideally you'd get
notifications if other people commit changes
that happen in parallel to yours, and will need
to be merged.)

...
> I should like svn to update the local copy automati-
> cally once the lock is issued, but it seems impossi-
> ble via server-side hooks, for they don't  have  ac-
> cess  the  user's woking copy where the file must be
> updated.

If you want such things you should visit clearcase,
with their basically-mandatory central file server.

...
> time it is locked?  As  I  understand,  it  requires
> customization  of  the  svn  client so that whenever
> asked to unlock a file it shall update it also.   Is
> it possible?

No. SVN clients may not even be online at that time.
Also I would seriously *not* want files to change
in my workspace e.g under a test run.

...
> Maybe, but I am under peer pressure, and TFS is  the
> alternative,  and  I think we still need it at least
> for "binary" files such as  MS  Word  documents.

Actually, we use svn for such purposes (non-mergable files),
and git for regular sources. Unfortunately I'm not the
svn side admin, so I can't tell how they do the locking.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Visualize when two branches have been merged

[Andreas Krey]

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 not
> all changes from the revision were merged.
> But that is the case for every version control system since merge commits
> are never a 1:1 mapping of changes, e.g. due to conflict resolution.

I'd still say that these are two different things (not merging the
entire tree but only selected files vs. dropping changes in the
actual merges).

In the first cases there is no mergeinfo for the files that are
not merged, and drawing a global merge arrow is arguably wrong.

But in the other case I do record the merge info even
if I then drop a merged-in change, essentially saying
"yes, I dropped this on purpose, and don't bring it
in again in the next merge". And the recorded mergeinfo
for the entire tree should be displayed as a merge info.

> The misconception seems to be that a conceptual 'merge arrow' implied
> a 1:1 mapping of changes, but it does not.

The fun thing is that a a merge is a symmetric operation with
respect to the contents, so if you don't draw the merge arrow
(second parent in git parlance) on that argument, you shouldn't
draw the straight line from the previous to the merge revision
('first parent') either. (Just as you can drop merged-in changes
in a merge conflict resolution you can as well drop changes
from the straight line.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Blocking root from SVN repository

[Andreas Krey]

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 server setup, only the server admin account could do so, and
only when the admin is logged onto the server.

 But regarding my question, if file:// is not intended to be used, as you 
 and Stefan Sperling argued, then what are the available options for 
 those who need a version control system and can't set up a server?

When you have a machine to place the file:// to, you also have
something to run a server on.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Vendor branches: Current guidance?

[Andreas Krey]

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 option of just doing a delete/add on the whole folder will mess 
 stuff up. 
 
 
 Is that correct? 

Yes. When you remove all the files and add them anew, svn will think
they are different files, and any attempt to merge that onto your own
modification will end in tears.

 If you don't use the client side tools, how can you maintain in-house changes 
 against a series of vendor drops? 

You need to use some kind of tool to perform the file-wise
add/remove/modifiy commits. Core svn doesn't provide such, it's somewhere
in the contrib area. (It's not that hard to implement yourself, either.)

But the best tool I know for that is actually git-svn. Because, if the
vendor renames files in his tree, with the usual tools the rename will
not be recorded as such in the vendor branch. git-svn applies its rename
detection, and will handle that part better.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: Re: Branch/switch/merge question

[Andreas Krey]

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 confuse the russians'

Seriously, -m 'fix #1234' if separate fixes are needed because
of code divergence. Occasionally. :-)

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: Re: svnmucc

[Andreas Krey]

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 newlines a command argument separator because there may be spaces
in files names is a regression from accepted CLI design, and doesn't
even solve the problem of newlines in file name which filesystems also
allow. Besides, hilarity also ensues there when a file happens to be named
'rm'.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: SVN Blame Returns Corrupt Data

[Andreas Krey]

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 character, not a control charactor.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Change all existing static externals in tags from operative to peg?

[Andreas Krey]

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 can't provide
a small repo that exhibits this behaviour, and lacking ideas as to why
this happens, I'm not interestet in taking the time to come up with
a big reproduction. And without that, no bug.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Change all existing static externals in tags from operative to peg?

[Andreas Krey]

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: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Migration from Clearcase to SVN

[Andreas Krey]

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 that in that generality. While old history may
be useless to have (and you have it in CC anyway), doing the switch on
a single state is unnecessarily harsh. Instead treat a succession of
states of the 'central' CC branch as a 'vendor branch' and import is
as such into svn. This allows you to continue to run out feature team
branches in CC until all of them have finished while being able to start
new teams on svn beforehand.

While you may not care about *old* history, the history during the
migration is highly helpful. Unless you can afford to do a single shot.

...
 * Under no circumstances maintain parallel work for the same project in
 Subversion and in the old Clearcase, and expect the Subversion history to
 be reconcilable with the parallel Clearcase history

While not trivial this is entirely possible as long as you only want
to sew the two systems together at a single branch (not transferring
the full history, just syncing).

 except by throwing out
 the Subversion repo and starting over from an import.

'Restart from scratch' seems to be a standard svn advice. :-(
(Usually meaning 'do a new checkout'.)

 If I meet one more
 oh-so-clever person who thinks reconciling such things is just a matter of
 a few lines of perl, I will throttle them with their own intestines.

Feel free to come over. I've been doing this for years between CVS and
git with twentyfour lines of shell script and proper procedure (which
is the hard part).

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Migration from Clearcase to SVN

[Andreas Krey]

On Sat, 20 Jul 2013 11:50:06 +, Nico Kadel-Garcia wrote:
 On Sat, Jul 20, 2013 at 2:16 AM, Andreas Krey a.k...@gmx.de 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 new VCS again, and
a single cut point doesn't even look feasible.

 The engineering
 time burned, and the bitter complaints about history discrepancies
 from fundamentally distinct history reporting can easily triple the
 cost and effort of the migration.

I'm promising transferring the cumulative changes,
not the exact history.

 It's also an excellent opportunity to *trim* the project. Bring over
 only relevant projects or source directories.

Oh, coming from clearcase it can be quite the pain to just get it
to compile and run again. There can be myriads of places in the
sources and buildfiles where pathnames start absolutely with
/vobs/... where your svn checkout never will be.

It can also be pretty painful to find out what *is* relevant.

...
  While not trivial this is entirely possible as long as you only want
  to sew the two systems together at a single branch (not transferring
  the full history, just syncing).

(I forgot to mention: 'syncing'. Not dealing with the same work
being done in CC and svn, slightly differently, and then expecting
that to merge well in any way. (But that is just like doing the
same work on two branches.)

 And it's possible to extract your own teeth, and theoretically
 possible to extract your own gall bladder. The clients will demand
 that it be resynced, and resynced, and won't understand why you can't
 just backfill the logs and changes from one system to the other, and
 you life will be filled with pain.  After all, they've got a few lines
 of perl that work great for them, why can't you just use them?

Just ask them to use their own few lines of perl to do that.

 And this is just what I'd worry about. I wrote that bit above before I
 saw this This is partially how I get paid. negotiating between
 developer's one-off hacks to something that's safe and stable for
 production use. It can be fun, but it can also be very, very expensive
 in manpower and beer while the details get worked out.

My client knows that. :-) Besides, the transfer is not (quite)
a production job; it needs to live for a limited time span, and
can require a bit of handholding. Yes, it won't work in half
an hour (or day, possibly week), but it is worth it to smooth
the transition.

 So you have few lines of perl that work generally,b ut for CVS, not
 Subversion, and expect it to work for Subversion? Admittedly, git is a
 relatively easy environment for such attempts  git has a similar model
 of master/tags/branches,

Forget the tags. 'Single branch'. What can be mapped into a succession of
tar files. I only track a succession of states of the master/trunk/MAIN
branch of the source repo into a vendor branch (to use svn parlance). That
is enough to be able to gradually phase out the old VCS and not needing
to do it in a single (long) instant where nobody can work. With a century
of developers I can invest a lot of time to save them a day of complete
downtime.

As soon as you try to figure out multiple branches and the
merge info you get into many-moons-project very fast.

 Subverrsion's trunk/tags/branches. So a lot of common cases are
 feasible. But man, the edge cases are *very expensive* to try to
 handle.

My current source repo also has very few strange and no non-ascii
characters in the filenames. :-)

 and the history back to Subversion. In fact, try backporting this from
 a working git repository into the Subversion hsitory:
 
  https://help.github.com/articles/remove-sensitive-data

No way. I'm aiming for what helps the migration, not for what might
be implementable given infinite ressources.

Basically, I'm one step away from you in the spectrum of possibilities;
you take a single snapshot; I take a single sequence of them.

 Been there, done that, can't be done on a live Subversion repo for a
 lot of reasons. (We could discuss why sometime, if you're interested.)

Beginning with 'svn obliterate' still not existing. But: Doing the
above (git filter-branching your repo) has similarly bad consequences
for your developers as dump-filtering an svn repo.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Subversion http protocol through SOCKS 5 server (with authentication)

[Andreas Krey]

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 internet (polipo may be a candidate).

If you only need to access a specific SVN host you may also
run a port forwarder that can use SOCKS5. Or do 'ssh -L
localport:desthost:destport helperhost' when you have something
ourside you can ssh to, and use netcat as a proxy command to
get through the socks proxy.

tsocks is by definition a hack that can't work in all circumstances.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Expected performance

[Andreas Krey]

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 the latter and claim that you didn't mention little details
 like an SSD for the working copy etc. Of course only because those
 would have only little impact on checkout performance... ;-)

No, that is an admittedly beefy machine with rotating rust
(although possibly raided), and GBit network access to the server.
Neither does the server have SSDs.

But the 1.5MByte/s that gets mentioned here seems quite unambitious;
with halfways decent hardware you should be able, in an svn checkout,
to saturate any network below 100MBit/s - the machine now under my desk
writes a tree of 10 files and 7GB in about a minute (that is
not an svn checkout).

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Check-out fails with LANG=C

[Andreas Krey]

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 filename
on the local disk by using the locally set LANG. This is a
rather stupid idea, but that is the way it is.

If you have any non-ascii chars in the file names in the
repo, no svn client should check out that repo while
under LANG=C.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Check-out fails with LANG=C

[Andreas Krey]

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 used in the file system is a property of the
file system or even individual directories and files, but certainly
not of the terminal session I'm using to do the checkout.

(And if you think that LANG should apply to file names on disk,
why would you think it should not do so for the file names that
come from the svn server in the checkout?)

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Check-out fails with LANG=C

[Andreas Krey]

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 UI and the disk interface. LANG tells the software
what language I want to use in the UI and how it should be encoded,
and is intended to be able to talk in different ways depending on what
terminal I use.

Tying the svn disk interface to that value is obviously tying this
property to the wrong object.

...
 So indeed, this state of affairs puts the burden of setting up their
 locale correctly on users, but that's simply the way Unix works.

No, it ain't. It's almost like the mailer looks into LANG to see
how to interpret the incoming mail, instead of using 'Charset:' etc.

Needing to do 'LANG=C svn info' to be able to grep for keywords
actually is the unix way, nowadays. en_us.utf8 is more appropriate
nowadays, howevery I can't remember how it's spelled.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Check-out fails with LANG=C

[Andreas Krey]

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 nightmares with existing working copies.

You could still make the encoding settable in the WC configuration,
and optionally make that default to utf8 in the checkout. Old WCs
wouldn't be affected. If the filesystem doesn't know, the application
should store a value. (This whole stuff is scary anyway.)

 I don't really understand what kind of answers you are hoping to get.

'You might have a point there'?

 Are you actually proposing that we change something in Subversion,
 or are you arguing out of spite?

False dichotomy? My spite is currently reserved for clearcase.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Expected performance

[Andreas Krey]

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?

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Expected performance

[Andreas Krey]

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 looks like 'bad'. I'd expect like a factor of ten more.

(C'mon, a local network can transfer that in 15 seconds, raw disk
performance isn't much worse either, and these aren't that many files.)

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: History in subversion

[Andreas Krey]

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 and load the history into a
 different one and change the revision numbers in the process, but that
 is a drastic administrative decision that will invalidate all
 checked-out workspaces.

Uh, it would also invalidate any pegged revision used in externals, right?

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: History in subversion

[Andreas Krey]

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 to the
 repository, your view is available immediatly on all the machines.

As I understand it, when you commit your stuff it also becomes immediately
visible in all other views that look at the same branch. That is a bit
disturbing.

Other than that, the dynamic view is an interesting tool to make
a workspace visible on multiple machines; normally you'd either
use NFS for that, or in 'commits are cheap and not carved in stone'
VCS systems, you just commit and move that commit over to the target.

 But I never saw another tool with these principles : real-time access to
 repository, build based on version (not on time), winkin,

We're at the point where simply compiling the sources on a local disk
is faster than winking in the objects in in clearcase.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Lines duplicated in dest. file when merging back to trunk

[Andreas Krey]

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 mieans 'different') on the branch, and you expect the
VCS to drop one of them?

It is obvious that both changes should be taken into the merge,
arguably (and usually) unless they are exactly the same, so SVN
does nothing wrong here.

The more interesting part is why you don't even get a conflict.
Apparently the exact place you do the modification in are also far
enough apart from each other so that the merge algorithm can take
them as independent chunks that affect disjunct parts of the original
file.

You should really go and cherry-pick such changes from one branch
to the other.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Tags - Symbolic names instead of Directory copy?

[Andreas Krey]

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 isn't good idea (because the tags you make of your project
wouldn't fix the externals to a tagged version).

And then you run into some workflow turbulence when you start modifying
within the externals.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Use Subversion to Manage Git?

[Andreas Krey]

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).

git rm files

Looks easier than hunting down a nonexistent plugin.
Otherwise, take a look at svnhub.com.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andreas Krey]

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 copy operation on a file system.

Now may be the time for what the germans call 'Merkbefreiung'. It has
been pointed out to you that a 'svn cp' is *not* 'nothing more' than
a tree copy; it records the source of the operation to support future
merge operations.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andreas Krey]

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 immutable out of the box, and have
the VCS not modify them with perfectly normal operations, at least not
without adding -f or something to them'?

 and why Subversion
 doesn't fulfill those requirements.

Just do 'svn cp /trunk /tag/thistag' twice accidentally,
and you see how it's bokren.

Subversion does not *support* tags (or branches), like C doesn't
support object-oriented programming. You can do the respective
things, but for instance, you can't ask subversion to tell you
the existing branches.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andreas Krey]

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, while Subversion doesn't.

You can always put them into the tag commit.

 Which useful info besides the name, and always present things like a
 revision, timestamps, who made the commit etc. is this?

Like 'which commit it is', in a useful way. Right now it is pretty
impossible to even find the tags that were made on commits of
a given branch's history. Like a 'svn log' that marks each
such commit with the names of the tags made there.

 And how does
 one benefit of those additional info compared to the lack of
 structuring of branches and tags those SCMs provide compared to
 Subversion?

All that structure is implicit. Unless someone tells you, you
have no ways to deduce which paths of a subversion repository
are meaningful to check out and which aren't.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andreas Krey]

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 can easily modify the same file in multiple
branches in the same commit. :-)

...
 Let's put it this way: if that was actually a tag then it could also be 
 argued that any file system supports branching/tagging.

Not quite, the file system does not store ancestry information on the
new partial tree. But svn's refusal to make tags write-protected by
default is the larger issue here.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andreas Krey]

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 directories are too abstract, and really not
 relevant. Why should I care how SVN implements its branches
 internally, as long as it works for the use cases I need?

It doesn't. Write protectings tags is obviously a pain in the ass;
anecdotalthe admins of 'my' production repo still didn't manage to
disallow additions to tag directories/evidence, and googling for the
problem doesn't even turn up any hints that are within the subversion
project pages. Let alone provide an easy way for users to override
that (like adding -f).

 The only concrete problem I've read so far (I don't remember if it was
 in this thread or another one) is that copying the parent of all
 branches (or tags) shows up as a revision when you svn log the
 branch. So okay, that's one thing. Any others?

The good old 'svn commit file; svn log' doesn't show the commit to
file issue?

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andreas Krey]

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 directory structure.[1]
If it ever doesn't anymore, it won't be SVN anymore.

Andreas

[1] Whether that is a good decision is an orthogonal question.
I don't think it was.

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andreas Krey]

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 or internal storage convenience, where
 git tracks changesets although it often has to generate complete
 revisions.

That indeed is just a misconception. git even goes to define exactly
how each commit (aka revision) is stored including its checksum.
This even though is it then going to internally store that in
a dense packfile format.

 The nature of branches seems to relate better to

No, the basic difference is that VCS operating on the whole tree can
only have branches (and thus merge info) on the whole tree either, so
you *can't* go like subversion does and map branches into the tree and
need to have them (and tags) as a separate concept.

SVN, instead of having branches as a separate concept, also stores whole
trees, but instead additionally stores 'this came from there' or 'that
was merged here' as a separate concept.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andreas Krey]

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 notion like this changeset is merged, that
one isn't, this is again, like in the 3-10,12-14 in the mergeinfo.

Each commit has a parent (or two in the case or a merge commit), and
it just computes the latest common commit and takes that as the
base for a 3-way-merge between the two branches in question.
(Ok, the merge base computation isn't that easy in more complicated
DAGs, but anyway.) If you merge again the end of the source branch
at previous merge time is the new merge base. Merge base computation
is what CVS utterly failed, and SVN for a long time being the better
CVS repeated that.

...
 I can see why it might be a problem to support concurrent nested
 branch changeset roots but that scenario is problematic any way you
 look at it.  Why would it be a problem to support parallel branching
 roots - perhaps with some enforcement on the source/dest top levels
 having some common parent?

I don't think I will understand this paragraph without more
terminology definition or examples.

  SVN, instead of having branches as a separate concept, also stores whole
  trees, but instead additionally stores 'this came from there' or 'that
  was merged here' as a separate concept.
 
 But does 'that was merged here', really know about the commit
 changeset where the change originated?

Only in the summarily way that it knows when a branch was merged
into another. Everything that is reachable through the commit
parent relation is 'merged in'. You can't selectively
merge specific comments (and record that). You only have
'merge arrows' that tell when everything of a branch was
merged into another, no lists of commits that got merged
(and that make merge algos take forever).

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andreas Krey]

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, I don't even think you can specify in git what to merge it just 
 merges all the changes.

Right; there is no list of commits that got merged, but only a second
parent pointer in the merge commit that points to the (then) head of
the branch.

 I think it is possible to do a cherry-pick, but I think that creates a diff 
 basically and applies that to the target.

Yes, except that it actually does a three-way merge with the current
branch head and the cherry-picked commit as the ends and the parent of
the cherry-pick commit as the base - this is more robust than applying
a patch.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: restoring a working copy from backup: can the pristine directory be recreated?

[Andreas Krey]

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 revision that was current when
the backup was made, and not a later that has committed changes
to the files in the sandbox. You'd undo those by unpacking the tar file.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Discrepancies in svn mirror created with svnsync

[Andreas Krey]

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: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: [ANN] SubGit 1.0.0 is released

[Andreas Krey]

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 maintaining  compatibility with a dynamic and
 evolving codebase, in another language.

Sorry, but this is just preemptive bad-mouting. The problem isn't that
there is no good good implementation of an svn server. The problem is that
the people working on that implementation aren't going to offer any path
that would enable other to integrate a git view on the repository. Heck,
they don't even offer a specified network protocol and insist that
*clients* use the C library.

So the only way to have a server that is viewable via git and via svn is
to rewrite the server. (Which is also good because the svn repo structure
is, well, suboptimal even for its own pourposes.) And there is obviously
enough public interest/suffering that subgit isn't even the first project
to do so - see svnhub.com.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: [ANN] SubGit 1.0.0 is released

[Andreas Krey]

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 subgit and don't talk for anybody but me.) 1.8 can't afford
to drop wire-compatibility with older clients anytime soon,
and the availablility of anything that can serve git and svn
clients will basically make any more svn updates unneeded.

 Subversion 1.8 is due out soon: and the merge
 technology is due for serious revision. Previous major releases of
 Subversion, with which I'm far more familiar than git, have included
 all sorts of desirable feature changes such as the switch from default
 Berkeley DB to FSFS, which seemed a great idea.

That particular switch really shoudn't affekt wire protocol. :-)

 I'm looking into your docs. That bi-directional, behind the scenes,
 2-way communication is *scary*.

Not mine. What you say sounds more like a marriage of the oritinal
servers by hook scripts, now a new server.

...
 It's closed source!

That's my personal reason not to look into that. :-) If I'd ever
go to design something along these lines, I'd forgo the full
svn compat and offer only the basic operations for svn clients, so
eclipse users and the like are happy, and do the rest on the git level.

Especially merging.

Im my opinion svn is simply outdated for the types of data I have to deal
with (that is, repos that are not going into the gigabytes range), and
the only thing that keeps people from massive migration is the need to
to interoperate old scripting/tools and the reluctant people who don't
actually care much for vesion control and are happy with committing
from time to time. As long as the latter chain 'us' to an svn server a
migration would be painful. As soon as there is a server that works on
git repos and can reasonably talk svn, a lot of switching will occur,
as a migration doesn't need to pull them along all the way at once anymore.

Perhaps I should put up a kickstarter? :-)

...
 That would be a lot of work for a limited benefit when the
 git-svn client tool works pretty well. Given that this toolkit
 already exists, it's the client access for Subversion clients to

No, git-svn doesn't unchain you from the svn server, nor can you ever
think of redoing your build/deploy in git terms. Most importantly,
you're chained to svn's merging - here we begin to check nontrivial
merges by trying them in git/git-svn and then seeing whether svn gives
us the same results.

...
 here! By keeping the software an integrated codebase for clients and
 servers, they're able to make protocol changes that you'll be forced
 to keep up with in an entirely distinct codebase. How can you *test*
 that robustly?

That is just shifting the problem. Either you have an API that you can't
just modify, or you consider the wire protocol your API, and either way
you have to be backwards-compatible and need something to test on that
level. (Besides in my opinion the wire protocol is only that complex
because you don't replicate - moving whole commits is easier than doing
all the commands remotely.)

 In theory, understandable. But Andreas, SubGit is closed source!
 Subversion has really, really benefited from the open source licenses.

Strong Ack. I wouldn't even look into github's svn access for serious
stuff for the same reason.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: Re: [ANN] SubGit 1.0.0 is released

[Andreas Krey]

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, that attitude is just as short-sighted and destructive
 to the open source community as is Lennart's crusade in Linux-land

Oh, I didn't mean that svn1.8 would be unnecessary; I meant that a server
working with git and svn clients would generally be a migrational tool and
wouldn't need to follow svn. I recognise that there are use cases for svn,
I just don't have any around here.

...
 There are different projects that fulfill different needs, and we
 should strive to keep them alive for as long as they serve a useful
 purpose to their users. Users should freely be able choose between
 tools and benefit from improvements made to each tool.

Systemd has the same problem as svn/git. They are not per-user decisions
but need to be made on a more global scale.

 In the grand scheme of things, the development of git is entirely
 orthogonal to the development of Subversion. They're different tools
 made for different requirements.

...with the problem that a lot of svn uses were decided back when git
wasn't known/available but git would be the proper tool now, were it not
for migration effort. subgit would lower that barrier.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: [ANN] SubGit 1.0.0 is released

[Andreas Krey]

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 some of the critics against
subgit and similar tools are simply not applicable.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: [ANN] SubGit 1.0.0 is released

[Andreas Krey]

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 like tags, which svn does not support?

You may also want to update on the current git feature set.

...
 clever engineer I knew who tried to write a source control system
 based on checked out branches having locked files owned by root and
 hardlinked to the original code. It sounded like an efficient idea on
 paper, but lord, it was painful to clean up after.

That bears a certain similarity with the history of merge support in svn
and the idea of implementing 'move' as 'copy+delete', the bugs caused by
which have still not been sorted out by the API-setting engineers.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: general questions

[Andreas Krey]

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. In your picture that whole set of all
commands available now or in the  future is the 'the application' for
which you'd need to design a GUI, would you want to have its flexibility
available in a GUI.

 different animals and if you mix the two its like trying to pull a
 trailer with a corvette.  It may work, it may cause problems.  It
 definitely is not optimal.

That's because a corvette isn't designed for a trailer hook. That
is exactly the situation with all kinds of GUis: Interaction
with *other* applications (the trailer) isn't designed in,
and can't be automated.

GUI applications are designed to interact with a user, and not with
other applications, and that is their general deficiency for some
kinds of work.

Try to get you browser and photoshop to play together and download,
scale, and publish a webcam pic every hour, and you see the non-power
of the GUI.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: general questions

[Andreas Krey]

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 important things. I've done such a thingie for myself for cvs;
you could just run update (where in svn you'd do status), click on
filenames to see the diff, and commit. Nothing more needes; the only
point was not to cutpase the filenames.

Interestingly I do the same with git on the command line because those
tools have gotten better and more streamlined there.

 And it would be very easy in incorporate *everything*.  Even
 command that have not been added yet.

You can't especially not shell invocations, as that would viod the spriti
of the GUI.

 Again, if necessary it can be, very easy.  However that is not the point
 of the wrapper.

Yes, it is. Imagine a GUI for 'svn status'. Now imagine how you'd
do the equivalent of 'svn status | awk '/I  / { print $2 } | xargs rm'
with that GUI, or even with the help of that GUI for the svn part.

Putting that in a script and name it svn-clean is two lines.
Putting that in a GUI (and esp. your svn status wrapper) is..how much?

...
 in designing a program.  They are not
 as limited as you believe them to be.

Programs aren't. GUIs are, exactly because of their primary goal.
They want to avoid the plugs and bolts at the outside, and thus they
aren't pluggable and boltable. (And yes, they do make many things
easier. And other things impossible.) Even Word has a CLI; even
though it's gruesome and called word basic.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: Re: UNS: SVN not usable on a Mac (#2464)

[Andreas Krey]

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 platfrom.

And moving outside of ASCII also has surprises with LANG=C, unfortunately.
(In my understanding LANG tells what console I/O should be, not how file
names are interpreted.)

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

svnadmin dump server shutdown

[Andreas Krey]

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 is running. (Nor does the backup section in the book.)

So: is it safe to run 'svnadmin dump' on an operational repo, and will it
dump up to the last revision at the time of its start or its termination?

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Externals: sqlite: constraint failed

[Andreas Krey]

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_module_V1.0.0/ant-scripts':
 svn: warning: W200035: sqlite: constraint failed
 

Ok, this was transient and didn't reappear.

Irritating, though. Do I still trust the WC?

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: Re: Externals: sqlite: constraint failed

[Andreas Krey]

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

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Externals: sqlite: constraint failed

[Andreas Krey]

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 cancellation. Is this the same working copy? If so, you might
 be seeing a side-effect of the bug you already reported.

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 - irreproducible.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: RE: Externals: sqlite: constraint failed

['Andreas Krey']

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 - irreproducible.
 
 Are you using a release build of Subversion or do you use a maintainer
 build?

No, it's self-built from the release tar files. (I assume 'maintainer
build' to mean to build from the checked out sources, including automake
etc.)

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Externals: sqlite: constraint failed

[Andreas Krey]

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-scripts':
svn: warning: W200035: sqlite: constraint failed


Lots of that (for a lot of externals), ending expectedly with


At revision 122958.
svn: E205011: Failure occurred processing one or more externals definitions


No other special occurrences; previous operations on that WC were
unproblematic. (This *may* have to do with a 'svn relocate' operation
on the WC, but URLs look ok.) It is a checkout of a tree containing a ot
of modules with trunk/tags/branches so there are many externals in the WC
(a few for each module trunk/tag).

Andreas


-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Externals: sqlite: constraint failed

[Andreas Krey]

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':
 External at revision 122958.
 
 svn: warning: W20: Error handling externals definition for 
 'module/tags/BUILD_module_V1.0.0/ant-scripts':
 svn: warning: W200035: sqlite: constraint failed
 
 
 Lots of that (for a lot of externals), ending expectedly with
 
 
 At revision 122958.
 svn: E205011: Failure occurred processing one or more externals definitions
 
 
 No other special occurrences; previous operations on that WC were
 unproblematic. (This *may* have to do with a 'svn relocate' operation
 on the WC, but URLs look ok.) It is a checkout of a tree containing a ot
 of modules with trunk/tags/branches so there are many externals in the WC
 (a few for each module trunk/tag).

And it's 1.7.4 against a pre-1.7 (1.6.6) server.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Can't kill svn

[Andreas Krey]

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'.

 When the signal is received, a flag is set that
 is checked next time Subversion invokes the cancellation handler which
 then cleans up state and causes an exit.

No, it doesn't. With 1.7.4:

| a:cc-svn-7 andreaskrey$ svn17 up -r85321
| Updating '.':
| Dtools
| Uivy.xml
| Usrc/
|  U   .
| 
| Fetching external item into 'ioc':
| Dmoda/CHANGES
| Umoda/h/...
(redacted output lists)
| Umoda/src/...
| ^Csvn: E200015: Caught signal

Ok, it did terminate, and fast.

But there is no 'graceful' in here:

| a:cc-svn-7 andreaskrey$ svn17 up -r85321
| Updating '.':
| 
| Fetching external item into 'ioc':
| svn: warning: W155004: Working copy '/Users/andreaskrey/cc-svn-7/ioc' locked.

...and that situation persists. graceful != requiring manual
intervention, as with 'svn cleanup'.

I only see the point of an arbitrary wait when svn then at least leaves
the sandbox in a state that doesn't require cleanup.

Incidentally, I only found that because I wanted to see if there is
still the cascade of

| svn: warning: Error handling externals definition for 'moda':
| svn: warning: Caught signal
| svn: warning: Error handling externals definition for 'modb':
| svn: warning: Caught signal
| svn: warning: Error handling externals definition for 'etc':
| svn: warning: Caught signal
| svn: warning: Error handling externals definition for 'ant-scripts':
| svn: warning: Caught signal

for a single ^C. Instead the wc is borked with:

| svn: Failed to add directory 'tools': an unversioned directory of the same 
name already exists

and a spurious conflict on svn:externals on the root (this with 1.6.6).
(svn is 1.6.6, svn17 is 1.7.4.)

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Can't kill svn

[Andreas Krey]

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 interrupt-able until that timeout.

...this being a 'feature' of svn, not the OS.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Can't kill svn

[Andreas Krey]

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': could not connect 
to server (http://217.140.74.17)
  
  real  1m14.898s
  user  0m0.007s
  sys   0m0.006s
  prompt 

I hit ^C shortly after hitting enter, but 1) svn doesn't stop
and 2) doesn't even seem to care about the signal received.

The only way to actually get rid of it is to ^Z and 'kill -9 %',
but this then requires a cleanup occasionally (plus the prayer
that the latter will work).

Andreas

Re: Revision/History Graph - DAG (Directed Acyclic Graph)

[Andreas Krey]

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
representation (single-revision merges, partial tree merges).

 I realize this could be tricky because of the implicit branching SVN 
 employs, but may be it's not impossible.  I imagine much of it could 
 be done using the copy source and merge-info data, though multiple 
 copy and merge sources for certain revision/changeset seem non-trivial.

Indeed. Straightforward cases go easier.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Revision/History Graph - DAG (Directed Acyclic Graph)

[Andreas Krey]

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 
 I haven't tried yet, but I've tried SVN to Mercurial using various 
 tools available for the task, and in my experience this conversion 
 is far from perfect, especially with weird repositories.

It necessarily is. Tools that map an svn repo into a DVCS one have
to deal with the fact that the latter 'only' have one global branch/merge
history while in svn potentially every file can have a completely
different DAG (and even reversed vertices).

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Revision/History Graph - DAG (Directed Acyclic Graph)

[Andreas Krey]

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 overview
and visible nodes.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: svn cl input from svn st

[Andreas Krey]

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: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: svn cl input from svn st

[Andreas Krey]

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 -e 's/^[A-Z]   \(.*\)$/\1/p'

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

['Andreas Krey']

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 build
task should automatically contribute to a list of files/directories to
be deleted on 'clean'. After all, e.g. a javac task incarnation knows
what directories it would create, so it can put them on the clean
list. (Speaking for ant here, other build tools may be smarter there.)

 Problem is, a clean task doesn't fail fast

It can't. Failure there is an omission to do something; which could at best
be noted after the fact by the output of 'svn clean -n' being nonempty.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Cannot accept non-LF line endings in 'svn:ignore' property

[Andreas Krey]

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 which of the seventeen
svn:ignore properties is the culprit.

But the real strange thing: I did only do a merge; not actually
edit any properties myself.

Is that coming from doing the merge on unix while most other
commits (and all of the properties) are done on windows?

Or is svn 1.7.x (the client) more picky? (But it looks like
a server message.)

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'.

Using a 1.7 client on an 1.5.few server.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Cannot accept non-LF line endings in 'svn:ignore' property

[Andreas Krey]

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'.
 
 Using a 1.7 client on an 1.5.few server.

..and it's the same with an 1.6.6 client.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Andreas Krey]

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 get such a feature? (This immediately begs the question why
there is an svn CLI client at all, and not just the library. ;-)

...
 However, it is still the developer's responsibility to make sure that
 their clean target cleans everything.

No actually; 'make clean' is responsible to clean up everything that
make produced, not 'everything', like editor backup files (or the
remains of aborted merges).

A 'throw out everything unversioned' VCS command comes in quite
handy when

- you switched branches before calling 'make clean' because now the
  .o file of some source existing only in one branch will be left over,

- you're simply trying to get 'make clean' to actually work and don't
  want to iterate through the 'svn status' output each time.

And 'remove; make new checkout' isn't always a valid workaround because
you may want to keep local modifications of versioned files.

Summary: There are a lot of reason not to implement a 'scrub the WC
of unversioned files', but in my opinion it's not our job isn't one
of them.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Andreas Krey]

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
 everything but your .svn directory and revert?

Typical VCS operations should not only be possible but also easy.
(And even the 'everything but .svn' part is tricky.)

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Andreas Krey]

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 so it works the same when you do it
 yourself as when automated.

Except for the part where not everyone should be forced to reinvent
the wheel of 'put the sandbox in a pristine state' as in 'cd ..;
rm -r $sandboxname; svn checkout -r $rev $url $sandboxname', but more
efficiently and without hitting the network.

While this is handy in a CI environment (since then we don't need to
deal with the specifics of the build procedure[1]) it is in no way
restricted to that case.

Andreas

[1] Like 'make clean' doesn't fully clean up because someone forgot to
commit the 'clean' rule for the new source's object file.

Or simply oops, we forgot to do 'make clean' before switching branches.

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Andreas Krey]

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 removed for a clean
working copy.

Likewise, svn forces me to use the \( -name .svn -prune \) clause
in all my find-greps, even though the presense of the .svn folders
is clearly svns business.

 Your CI tool is should clean up itself.

That would be not the CI tool but the entire build system, potentially
including editors used etc. pp. (CI being just an example of the usefulness
of an hypothetical 'svn cleanup'.) We go the way of keeping a clean
sandbox and making a copy of it for each build.

And it's not as if svn itself always cleans up after itself.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Andreas Krey]

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
 how adding a new command to subversion that would do the equivalent of
 deleting everything except svn metadata followed by a revert and maybe
 an update helps with VCS independence.  Your CI already has to know
 how to use each VCS independently anyway.

Yes. But knowing to invoke 'svn update' and 'svn cleanup -fdX' is somewhat
different from knowing to svn status --no-ignore | awk '/^I / {print $2}'
| xargs rm -rf (or similar) with all the caveats that come with strange
characters in file names.

If you argue that a CI/XY tool should find out for itself what files are
not under svn control then one could argue analogously that it should
as well bypass svn for doing updates. :-)

But then, svn currently has more important issues than implementing
'svn cleanup'.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Feature request: allow for relative working copy paths in svn:externals definition

[Andreas Krey]

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-a
   svn checkout http://your/soft/ware/trunk dir-b

in one and the same directory (namely $HOME, where I do this all the
time).

 Software should adopt as good as possible to the
 existing workflow/structures. There should be no
 need to completely rearrange projects just to get what one wants only

'completely rearrange' is a bit harsh for putting the CommonFiles
external within instead of besides the tree checked out. Besides,
the very idea of letting a checkout/clone create files outside
of the target directory I specified is foreign to all other version
control systems I used so far.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: Re: How do I diff a large svn:externals file

[Andreas Krey]

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.

1.7 changed that.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: commit hooks - is there a hook which is called after commit even if its not successful

[Andreas Krey]

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 depending on the commit size.

Put the pre-commit hook work aside (which you need to do anyway),
and when no post-commit hook has picked it up for, say, 15 minutes,
discard it. If the server should really be that slow, then you
will have to recreate the stuff, but only then. You can do the
expiry check in the post-commit trigger; you may also look
at the (monotonical) revision number.

I don't expect there to be a guarantee that there is only ever
one set of hooks (pre-hook/commit/post-hook) running, so you need
to deal with multiple work sets anyway.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: svn copy randomly gets File or directory is out of date error

[Andreas Krey]

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: resource out of date; try updating 

At the very least the error messages are misleading:
There is nothing that could be updated in this case.

 Server-side copies can fail if they compete with concurrent commits.

Seriously, what competition? What reason even is there to allow
a purely server-side operation to run into a can't-continue state
due to other commits -- and not let those commits (that are late
to the race to begin with) fail?

The message should really be

  svn: I don't feel like it, please retry.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: SVN backup with lvm snapshots and rsync

[Andreas Krey]

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 recommendation to use it at all.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: switch to ignore files that have not been checked in?

[Andreas Krey]

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 working.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Unreferenced pristines behavior in 1.7

[Andreas Krey]

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 will be lying around; after committing twenty versions
of a file you have nineteen unreferenced pristines there.

...
 I am actually in the process of doing an all-branches checkout right
 now, to try and take advantage of the consolidation available in the
 new working copy format.

Unfortunately the consolidation only affects the pristines; you still
have separate copies of identicat files in the working copy.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: svn and autoconf

[Andreas Krey]

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 you can not count on 
 the timestamp order to be consistent.  It seems that after a checkout 
 make sometimes thinks a target is out of date and other times it doesn't.

Correct.

...
 This seems like a general issue with subversion any time a target and a 
 dependency of that target are both in the repository.

This is not subversion-specific (except that a similar quirk lurks
in the subversion sources). Putting a target under version control
is the exact opposite of 'source code control'; there will always be
issues with make (or other) dependencies, independent of what time
stamps a checkout produces..

 Does any body know of a good way to resolve this?  Clearly I can touch 
 configure before I make, but I am looking for a more general and 
 automated solution.

Don't put 'configure' under version control. Expect people who use
a checkout to have 'autoconf' installed (yuck).

When producing a release .tar file that shall not use autoconf,
run autoconf, remove the autoconf rule from the makefile, and
tar the result (with or without configure.in).

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Assertion failed and crash with 1.7.1

[Andreas Krey]

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 .

does *not* report some of the externals that

  svn pg -R svn:externals some/sub/path

reports.

It being a large (and proprietary) repo and only occurring when recursing
over big parts of it, I didn't go to try to reproduce it for a bug report.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: UNS: updating a remote copy of SVN

[Andreas Krey]

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 bit more complex
 
 I have three machines:
 
 A - which maintains the a remote subversion tree

(I assume that to mean 'the svn server'.)

 B - A cluster where I would like to do some development but cannot see A
 C - A machine which can see both A  B
 
 How can I use C to update the subversion archive on B from A?

Depends on how you access svn. Assuming http:// and that you can
use that from C.

On C:

C  ssh B -R 8080:A:80
B  svn checkout http://localhost:8080/path/to/repo wcname

 Firewalls stink!

The real stink is that you may break some company policy using this method
(though improbable).

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: merge disagrees with diff

[Andreas Krey]

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 target.

You didn't get a clean merge; you got a conflict. When you get a conflict,
it is your job to look at what you merged and at the proposed result,
and resolve it yourself. 

Here it may simply be that you get the conflict because you want to merge
in the addition of a block of code but in the merge target surrounding
(here: following) blocks have been removed. Now you get all of those
within the conflict marker. (Can't tell without the three versions
that have been requested.)

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: merge disagrees with diff

[Andreas Krey]

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 described in the
book. It is true that if you merge the change from A to B into C and
get D, then diff(A,B) should be the same as diff(C,D). But this holds
only when there are no conflicts.

Example. A is:

  one
  two
  three
  four
  five
  six
  seven

Add a line to get B:

  one
  two
  three
  three two thirds
  four
  five
  six
  seven

Meanwhile for C we have removed a few lines:

  one
  two
  three
  six
  seven

And now we merge the diff(A,B) onto C and get:

  one
  two
  three
   HEAD
  ===
  three two thirds
  four
  five
   work
  six
  seven

which means it looks like the merge is bringing in 'too much', but what
it is actually showing is that between the lines 'three' and 'seven'
that were in the baseline version of the file (A) there are no lines
left in C and three lines, partially 'new', in B.

In essence, svn sees only two different (and conflicting) changes to
a block of lines, and leaves it to you to deal with that. (Likewise
do git and CVS.)

This looks pretty much like your situation.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Help! Subversion Exception!

[Andreas Krey]

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 to 1.7. Imagine that on a multiuser system where svn is
installed as RPM/simile.

...
 Have users always run 'svn cleanup' before they leave for the night on
 any wc's that they ^C'd during the day?

How about setting a 'busy' flag while svn is executing, and calling
for the user to invoke 'svn cleanup' if it is still set on invocation?
Ok, too late for that.

Apart from a) the fact that under circumstances ^C does not work (in
seems to be caught but not handled everywhere in a timely fashion, and,
that being the case, how can svn really break the WC) and I need to
'^Z/kill -9 %' it (the server connect takes a little longer where I am
sometimes) and b) that svn sometimes explicitly asks to run 'svn clean'
which in exactly those cases failed to clean up.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Problem with diff

[Andreas Krey]

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 subject from the tar file or directly from svn?

The funny thing is that the resulting diffs do not only differ from
the expected result but are also different between machines.

That's why I wanted to build for Solaris: To see what happens there.

...
   My apple produces (without any svn:prop):

Plain 10.5.8 with compiler from xcode, compiled from source. Probably 32bit.

   +   450    IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
   +   451 END.

   and the linux box makes that

SuSE 10.2, Kernel (irrelevant) 2.6.18.8-0.3, apparently 64bit executable.

   +   452 {ws_i/log.i}
   +

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: 1.7.0 does not build on Solaris9

[Andreas Krey]

On Wed, 19 Oct 2011 10:36:28 +, Philip Martin wrote:
 Andreas Krey a.k...@gmx.de 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
 
  make EXTRA_LDFLAGS=-lz

ldd already tells me the line 'libz.so =   /usr/lib/libz.so'
which is a bit irritating because why did get-deps pull zlib in the
first place when it uses the system one?

/usr/lib/libz.so does not seem to have any symbol containing 'Bound',
thus probably being before 1.2.0.

  make EXTRA_LDFLAGS='-lz -L/some/dir'

That will be useful for -lintl.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Problem with diff

[Andreas Krey]

On Tue, 18 Oct 2011 08:55:44 +, Daniel Shahaf wrote:
  
  as the diff.
  
  But happens only with this specific file; can't reproduce with
  other content.
  
 
 Does the file (either before or after the append) contain two identical
 lines?  If so, could you try replacing each line in the file by a unique
 string?  You can do that with
 
 % perl -lne 'print $h{$_} ||= $unique++' \
   kadr.polon.p kadr.polon.p.anonymized


Nice trick, but unnecessary. The original file was an attachment on the
mail I replied to.

But that does not trigger the bug:

===
--- kadr.polon.p(revision 1)
+++ kadr.polon.p(revision 2)
@@ -450,3 +450,5 @@
 369
 370
 371
+
+/**/

Passing the file through rot13: Bug stays:

===
--- kadr.polon.p(revision 1)
+++ kadr.polon.p(revision 2)
@@ -461,6 +461,8 @@
RZCGL GRZC-GNOYR gg_glganhx.
RZCGL GRZC-GNOYR gg_fganhx.
cBfgngav = iVybfp.
+   VS iVybfp = (cFgneg + cVybfp - 1) gura yrnir Tybony_ybbc.
+RAQ.
VS iVybfp = (cFgneg + cVybfp - 1) gura yrnir Tybony_ybbc.
 RAQ.
 {jf_v/ybt.v}

Replacing each char by another one (individually, not caesar).
But stays, though no duplicate lines:

===
--- kadr.polon.p(revision 1)
+++ kadr.polon.p(revision 2)
@@ -461,6 +461,8 @@
TVJBN TKFW-NXNXO kr_sqeujxy.
KUNPS UABP-ASKTF rj_lgdujj.
aOxxrupn = tMjwdl.
+   IA dOjubh = (hZnfpq + wPykty - 1) flse cbfgj Onaorw_svvq.
+AKM.
IA dOjubh = (hZnfpq + wPykty - 1) flse cbfgj Onaorw_svvq.
 AKM.
 {iv_c/dpv.r}

Using cat -n on the file: Bug stays, even more surprisingly:

===
--- kadr.polon.p(revision 1)
+++ kadr.polon.p(revision 2)
@@ -461,6 +461,8 @@
447EMPTY TEMP-TABLE tt_tytnauk.
448EMPTY TEMP-TABLE tt_stnauk.
449pOstatni = vIlosc.
+   450IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
+   451 END.
450IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
451 END.
452 {ws_i/log.i}

So, it is not the line uniqeness, but rather it looks like having to do
with the line length structure.

I really like to see *that* patch.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Problem with diff

[Andreas Krey]

On Tue, 18 Oct 2011 10:22:33 +, Daniel Shahaf wrote:
...
 371 != 450+3, so there are some duplicate lines.

Yes. I forgot to say it's source code, so of course there are dups. :-)

...
  Replacing each char by another one (individually, not caesar).
  But stays, though no duplicate lines:
  
 
 Huh?  This transformation doesn't deduplicate, there were duplicate lines
 to begin with, so the result should also contain duplicates.

Er, it does. Each character is replaced by a random one, and the
next same character by another random one, so '' becomes 'ehaf'
(or 'qrhs' or whatever, of course).

..
  I really like to see *that* patch.
  
 
 Which one?  The one introducing the bug or fixing it?
 

The fix, where it is easier to see what went wrong (hopefully in the
commit message). Gotta be interesting. Didn't even think to bisect for
the regression up to now.

Is the diff engine separate from the delta computation?

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Problem with diff

[Andreas Krey]

On Tue, 18 Oct 2011 10:32:36 +, Daniel Shahaf wrote:

 
 Thanks for the self-contained recipe!

Is the only sane way to do such stuff.

 Using it I cannot reproduce the bug using either 1.6.12, 1.7.0, or
 trunk.  I'm on a 32-bit Linux system, using apr/apr-util as shipped with
 httpd 2.2.19/2.3.15; I'll try later in other environments.

Is not supposed to be in 1.6.2. I'm on vanilla macos 10.5.8, self-built,
with apr from deps. Can't deduce 32/64 bits right now (need to leave train).

Andreas

Re: Problem with diff

[Andreas Krey]

On Tue, 18 Oct 2011 17:54:41 +, Daniel Shahaf wrote:
...
 svnmucc, and then append two lines and diff before/after committing,
 but still couldn't reproduce your issue.

I can't reproduce it on the linux box, either. At least not exactly.
This is going to be fun.

My apple produces (without any svn:prop):

===
--- kadr.polon.p(revision 1)
+++ kadr.polon.p(revision 2)
@@ -461,6 +461,8 @@
447EMPTY TEMP-TABLE tt_tytnauk.
448EMPTY TEMP-TABLE tt_stnauk.
449pOstatni = vIlosc.
+   450IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
+   451 END.
450IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
451 END.
452 {ws_i/log.i}

and the linux box makes that

===
--- kadr.polon.p(revision 1)
+++ kadr.polon.p(revision 2)
@@ -463,4 +463,6 @@
449pOstatni = vIlosc.
450IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
451 END.
+   452 {ws_i/log.i}
+
452 {ws_i/log.i}

Uninitialized variable that then points to the wrong lines?

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

1.7.0 does not build on Solaris9

[Andreas Krey]

When building subversion 1.7.0 on Solaris9 I get a strange error:

/bin/bash /export/home/krey/sub1.7.0/libtool --tag=CC --silent --mode=compile 
gcc -DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE  
-g -O2  -g -O2 -pthreads  -D_LARGEFILE64_SOURCE -DNE_LFS  
-I./subversion/include -I./subversion -I/export/home/krey/sub1.7.0/apr/include  
 -I/export/home/krey/sub1.7.0/apr-util/include -I/usr/local/include/neon 
-I./serf -I/export/home/krey/sub1.7.0/sqlite-amalgamation   -o 
subversion/libsvn_subr/simple_providers.lo -c 
subversion/libsvn_subr/simple_providers.c
/bin/bash /export/home/krey/sub1.7.0/libtool --tag=CC --silent --mode=compile 
gcc -DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE  
-g -O2  -g -O2 -pthreads  -D_LARGEFILE64_SOURCE -DNE_LFS  
-I./subversion/include -I./subversion -I/export/home/krey/sub1.7.0/apr/include  
 -I/export/home/krey/sub1.7.0/apr-util/include -I/usr/local/include/neon 
-I./serf -I/export/home/krey/sub1.7.0/sqlite-amalgamation   -o 
subversion/libsvn_subr/skel.lo -c subversion/libsvn_subr/skel.c
/bin/bash /export/home/krey/sub1.7.0/libtool --tag=CC --silent --mode=compile 
gcc -DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE  
-g -O2  -g -O2 -pthreads  -D_LARGEFILE64_SOURCE -DNE_LFS  
-I./subversion/include -I./subversion -I/export/home/krey/sub1.7.0/apr/include  
 -I/export/home/krey/sub1.7.0/apr-util/include -I/usr/local/include/neon 
-I./serf -I/export/home/krey/sub1.7.0/sqlite-amalgamation   -o 
subversion/libsvn_subr/sorts.lo -c subversion/libsvn_subr/sorts.c
none ./build/transform_sql.py subversion/libsvn_subr/internal_statements.sql 
./subversion/libsvn_subr/internal_statements.h
/bin/bash: none: command not found
make: *** [subversion/libsvn_subr/internal_statements.h] Error 127

It seems that ./configure does not know enough about this kind of system,
or does libtool? Or is there missing a check for 'none'?

[Build from subversion-1.7.0.tar.bz2 plus what get-deps.sh drags in;
 the dragging being done on another machine.]

How do I get to compile that?

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: 1.7.0 does not build on Solaris9

[Andreas Krey]

On Tue, 18 Oct 2011 21:53:31 +, Andreas Krey wrote:
...
 none ./build/transform_sql.py subversion/libsvn_subr/internal_statements.sql 
 ./subversion/libsvn_subr/internal_statements.h

Hmm. Actually it seems tht that the python detection is skimpy.
Is that required?

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: 1.7.0 does not build on Solaris9

[Andreas Krey]

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, after an '#include unistd.h' in the sqlite amalg (for ftruncate),
a few touches on the generated .h, and re-invoking the linker commands
(quite a few) with an -lintl added, I seem to have a binary.

But svnadmin greets me with:

+ svnadmin create repo 
svnadmin: Version mismatch in 'svn_delta': found 1.5.5, expected 1.7.0
svnadmin: Version mismatch in 'svn_fs': found 1.5.5, expected 1.7.0
svnadmin: Version mismatch in 'svn_repos': found 1.5.5, expected 1.7.0
svnadmin: Version mismatch in 'svn_subr': found 1.5.5, expected 1.7.0

:-(

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: 1.6 to 1.7 migration : Subversion Exception when doing SVN Upgrade Working Copy

[Andreas Krey]

On Mon, 17 Oct 2011 11:42:13 +, Christophe Franco wrote:
 Hello
...
 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
  line 1935: assertion failed (svn_checksum_match(entry_md5_checksum,
  found_md5_checksum))


To quote Andy Levy andy.l...@gmail.com from about yesterday:
| ...
|  http://subversion.apache.org/mailing-lists.html
|
|This is very important. Please do it. You'll find an answer that way.
|
| You had a broken working copy that can't be upgraded.
| http://svn.haxx.se/tsvnusers/archive-2011-10/0086.shtml

...practically meaning that the WC 1.6-1.7 conversion code can't really deal 
with
what 1.6 typically leaves behind in the sandbox. (This is documented but yet the
cleanup does not always seem to be enough...)

Andreas

--
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Problem with diff

[Andreas Krey]

On Mon, 17 Oct 2011 14:21:02 +, Adam Miazga wrote:
 Hi.
 
 I have one magick file (in attachment).
 I commit this file to repository. I add line
 /**/
 into end of file. And again I commit the file to repository.
 
 When i invoke svn diff -r n:m kadr.polon.p i recive
 
 in Subversion 1.6
 Index: kadr.polon.p
 ===
 --- kadr.polon.p(revision 7)
 +++ kadr.polon.p(revision 8)
 @@ -463,3 +463,5 @@
IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
 END.
 {ws_i/log.i}
 +
 +/**/

Same here (with -rc2, actually). Run:

=
#!/bin/sh
rm -rf svntmp
mkdir svntmp
cd svntmp
svnadmin create repo
svn checkout file://`pwd`/repo wc
cd wc
cp ../../kadr.polon.p .
svn add kadr.polon.p 
svn commit -m 1
cat kadr.polon.p EOF

/**/
EOF
svn diff
exit
=

in a directory with the original file and get

===
--- kadr.polon.p(revision 1)
+++ kadr.polon.p(working copy)
@@ -461,6 +461,8 @@
EMPTY TEMP-TABLE tt_tytnauk.
EMPTY TEMP-TABLE tt_stnauk.
pOstatni = vIlosc.
+   IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
+END.
IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
 END.
 {ws_i/log.i}

as the diff.

But happens only with this specific file; can't reproduce with
other content.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Huge diff for one-line change in ASF repository

[Andreas Krey]

On Sat, 15 Oct 2011 10:41:57 +, Les Mikesell wrote:
...
 But a binary EOL is almost never works for cross platfom text.  Which
 is why systems designed for cross platform work do the conversions.
 How do git users deal with it?

Only relatively lately, by some local setting that actually does the
CR/LF conversion (iirc core.autocrlf). Details are somewhat intricate.
There may also be hooks that would allow expansion/shortening of
stuff at least similar to $Id$.

As for $Id$, the git way is to compile the output of 'git describe
--dirty' or similar into the binaries, which will show the last tag
(something I don't even know how to find out in svn) reachable from
the current commit/revision, the number of commits since, (part of)
the current commit id and whether there is a local modification in
the sandbox.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Exception! text change?

[Andreas Krey]

On Fri, 14 Oct 2011 08:23:21 +, Cooke, Mark wrote:
...
  Subversion encountered a serious problem.
  
  Please search the mailing list archives for the error message, as
  a solution may already be available (this also avoids reporting the
  same problem repeatedly).  You can find the mailing list archives
  at http://subversion.apache.org/mailing-lists.html.
  
  If you cannot find anything, please take the time to send as much
  information as possible about what you were trying to do along with
  the following information (you can copy the content of this dialog
  to the clipboard using Ctrl-C) to the Subversion mailing list
  (users@subversion.apache.org).  Many thanks!
 
 
 I think this might help (or am I hopelessly optimistic)?

Yes. :-) It would be more helpful it TSVN would include some information
about what it was just doing right in the popup box.

Andreas

-- 
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800