Repair corrupt repository

[Brad Waldon]

Hi

I am looking for expert help in Brisbane, Australia to repair a corrupt 
repository. Svnadmin verify returns "Decompression of svndiff data failed" at 
an earlier revision.

We use SVN for document management and don't have the expertise and time 
internally to resolve.

Regards

Brad Waldon / Director

Waldon Services Pty Ltd
E:  b...@waldonservices.com
W: www.waldonservices.com

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

[Bob Archer]

> On Sat, May 11, 2013 at 10:50:12PM +0100, Zé wrote:
> > You're missing the point.  The point is that subversion could be even
> > better than what it already is if it actually supported branches.
> 
> OK, I would also like Subversion to get better, so we agree here.
> 
> Now, what kinds of improvements would you hope to gain from adding a first-
> class concept called "branch" to the current system?
> 
> Keep in mind that adding a new dimension to the current repository data model
> is a huge amount of work. We need a design spec that is solid, and we need to
> have a very good idea of how to implement that design, using the current
> system as a starting point.
> 
> We need to know how all existing operations will be affected by the extended
> data model, and how they need to behave in the new data model.
> We need to define use cases and test cases for any new behaviour.
> 
> We need to know if and how these changes affect our two network
> communication protocols, and perhaps implement changes there.
> 
> And it also needs to be backwards compatible all the way back to SVN 1.0.

That is only true if this change is 1.something. But, if it is 2.0 then the svn 
rules allow for a break in backward compatibility. 

What I don't understand is why someone argues about how git does something is 
better yet uses svn. Use the tool that works for you, or works the way you 
expect a tool to work. 

BOb

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

[C. Michael Pilato]

On 05/13/2013 10:04 AM, Bob Archer wrote:
> What I don't understand is why someone argues about how git does
> something is better yet uses svn. Use the tool that works for you, or
> works the way you expect a tool to work.

Oh, I'm sure if we tried we could all think up plenty of reasons why someone
might argue the superiority of one tool over another and yet use "the
other".  Perhaps the superiority isn't universal -- only some features are
better, while some lack.  Perhaps the choice of tool isn't available for one
reason or another.  Whatever.  It hardly matters here -- on this list -- why
someone who likes Git also uses Subversion.

What matters is the desired outcome of the discussion.  This list is about
Subversion.  OtherVCSystem fanboyism isn't welcome here, not because it's
fanboyism (which is just intellectually pathetic) but because it's
off-topic.  But merely pointing out things that Git does better (in
someone's approximation) than Subversion isn't necessarily fanboyism.  And
if the point of comparing Subversion to Git or Hg or OtherVCSystem is to
find ways to make Subversion a better product, that's completely on-topic
and welcome (so long as the discussion is handled maturely).

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

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

[Les Mikesell]

On Mon, May 13, 2013 at 9:04 AM, Bob Archer  wrote:
>
> What I don't understand is why someone argues about how git does something is 
> better yet uses svn. Use the tool that works for you, or works the way you 
> expect a tool to work.

Or, learn what to expect from the tool you use...   If I followed the
thread correctly, the 'problem' involved was not expecting subversion
to consider a directory rename as a change to everything below.   If
you know that subversion doesn't know/care about the location of what
you think of as the 'project', you could simply position it so that
you wouldn't need to rename the directories above the branches.  Or at
least not be surprised when subversion sees that as a change.

--
   Les Mikesell
 lesmikes...@gmail.com

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

[Bob Archer]

> On 05/13/2013 10:04 AM, Bob Archer wrote:
> > What I don't understand is why someone argues about how git does
> > something is better yet uses svn. Use the tool that works for you, or
> > works the way you expect a tool to work.
> 
> Oh, I'm sure if we tried we could all think up plenty of reasons why someone
> might argue the superiority of one tool over another and yet use "the other".
> Perhaps the superiority isn't universal -- only some features are better, 
> while
> some lack.  Perhaps the choice of tool isn't available for one reason or 
> another.
> Whatever.  It hardly matters here -- on this list -- why someone who likes Git
> also uses Subversion.
> 
> What matters is the desired outcome of the discussion.  This list is about
> Subversion.  OtherVCSystem fanboyism isn't welcome here, not because it's
> fanboyism (which is just intellectually pathetic) but because it's off-topic. 
>  But
> merely pointing out things that Git does better (in someone's approximation)
> than Subversion isn't necessarily fanboyism.  And if the point of comparing
> Subversion to Git or Hg or OtherVCSystem is to find ways to make Subversion a
> better product, that's completely on-topic and welcome (so long as the
> discussion is handled maturely).

Yes, I get what you are saying. But, to claim the way svn supports branches and 
tags is a "hack" doesn't seem like a productive conversation. It is far from a 
hack and that statement dismisses all the hard work of design and 
implementation that went into svn almost dismissing the whole team many of 
which are volunteers.

It would be nice if branches could become a first class object with the branch 
command being very specific. But, what we have is far from a hack if you 
understand how it works. 

I would like to see more "first class" support for projects and/or defining a 
project root. For example, perhaps there can be an svn:projectroot property 
that must be on a folder and the branch/merge command will only work on project 
roots. If that is done of course the maintain backward compatibility there 
could be a switch in the client config to allow for bypassing this requirement, 
or perhaps the --force switch could do it. Also, a property can be place on a 
branch so that tooling can know it is actually a semantic branch rather than 
just a fork (copy).  

Issue: unicode characters in file names

[Адолин Негаш]

Hello

I have svn files with unicode chars. When I try to view files, I get  an
error message:

'
https://srv01/svn/SQLServer/Main/BackOffice/Security/Procedures/%5BSecurity%5D.%5BPrivileges::Groups::View(Delphi)%5D.sql'
doesn't exist

But when I access revision via browser, there is no error, and I can
successfully download the file.

Version information:

Windows 7, 64 Bit

TortoiseSVN 1.7.12, Assembly 24070 - 64 Bit , 2013/03/29 08:00:43

Subversion 1.7.9, 

apr 1.4.6

apr-utils 1.3.12

neon 0.29.6

OpenSSL 1.0.1e 11 Feb 2013

zlib 1.2.7

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

[Stefan Sperling]

On Mon, May 13, 2013 at 03:21:15PM +, Bob Archer wrote:
> I would like to see more "first class" support for projects and/or
> defining a project root. For example, perhaps there can be an
> svn:projectroot property that must be on a folder and the branch/merge
> command will only work on project roots. If that is done of course the
> maintain backward compatibility there could be a switch in the client
> config to allow for bypassing this requirement, or perhaps the --force
> switch could do it. Also, a property can be place on a branch so that
> tooling can know it is actually a semantic branch rather than just a
> fork (copy).  

This idea has been discussed before and could still be viable in
the future.

Some references to start browsing:
http://svn.haxx.se/dev/archive-2009-09/0156.shtml
http://svn.haxx.se/dev/archive-2011-10/0065.shtml

Re: Issue: unicode characters in file names

[Andy Levy]

On Mon, May 13, 2013 at 11:23 AM, Адолин Негаш  wrote:
> Hello
>
> I have svn files with unicode chars. When I try to view files, I get  an
> error message:
>
> 'https://srv01/svn/SQLServer/Main/BackOffice/Security/Procedures/%5BSecurity%5D.%5BPrivileges::Groups::View(Delphi)%5D.sql'
> doesn't exist
>
> But when I access revision via browser, there is no error, and I can
> successfully download the file.

When you download the file, are the colons preserved in the filename?
Colons (:) are reserved characters in NTFS, and you shouldn't be able
to create a filename containing them.

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

[Les Mikesell]

On Mon, May 13, 2013 at 10:37 AM, Stefan Sperling  wrote:
>
>> I would like to see more "first class" support for projects and/or
>> defining a project root. For example, perhaps there can be an
>> svn:projectroot property that must be on a folder and the branch/merge
>> command will only work on project roots. If that is done of course the
>> maintain backward compatibility there could be a switch in the client
>> config to allow for bypassing this requirement, or perhaps the --force
>> switch could do it. Also, a property can be place on a branch so that
>> tooling can know it is actually a semantic branch rather than just a
>> fork (copy).
>
> This idea has been discussed before and could still be viable in
> the future.

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.   The nature of branches seems to relate better to
changesets since you are likely to want to merge/apply the same
changesets to different places - but, if you track the changesets you
have to anchor those changes to the tree that was the base for the
changes.

--
   Les Mikesell
 lesmikes...@gmail.com

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 
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?

[Les Mikesell]

On Mon, May 13, 2013 at 12:23 PM, Andreas Krey  wrote:
> 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.

What it computes internally or uses as an internal storage isn't quite
the point.  Svn would also always compute the differences even though
it really only cares about the full revisions.What does git do if
you try to double-merge a change?  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?

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

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?

> 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?

--
   Les Mikesell
  lesmikes...@gmail.com

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

[Bob Archer]

> On Mon, May 13, 2013 at 12:23 PM, Andreas Krey  wrote:
> > 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.
> 
> What it computes internally or uses as an internal storage isn't quite the 
> point.
> Svn would also always compute the differences even though
> it really only cares about the full revisions.What does git do if
> you try to double-merge a change?  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?

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. I think it is possible to do a cherry-pick, but I think 
that creates a diff basically and applies that to the target.

BOb



> 
> >> 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.
> 
> 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?
> 
> > 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?
> 
> --
>Les Mikesell
>   lesmikes...@gmail.com

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 
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 
Date: Fri, 22 Jan 2010 07:29:21 -0800