date:20111020

Dimitry Gavrilov wrote on Wed, Oct 19, 2011 at 18:27:11 +:
> Hi,
> 
> I installed tortoise 1.7 64-bit version on Win 7.
> 
> I am getting the below error constantly while trying to commit or merge to 
> branches.
> 
> What should I do?
> 

That looks like a new bug, thanks.

Do you know how to reproduce this error, preferably starting from an
empty repository or a publicly readable one?

> ---
> Subversion Exception!
> ---
> Subversion encountered a serious problem.
> Please take the time to report this on the Subversion mailing list
> (users@subversion.apache.org)
> with as much information as possible about what
> you were trying to do.
> But please first search the mailing list archives for the error message
> to avoid reporting the same problem repeatedly.
> You can find the mailing list archives at
> http://subversion.apache.org/mailing-lists.html
> 
> Subversion reported the following
> (you can copy the content of this dialog
> to the clipboard using Ctrl-C):
> 
> In file
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\wc_db.c'
> line 7393: internal malfunction
> ---
> OK
> ---
> 
> Dimitry Gavrilov
> Senior Lead Engineer
> 
> [Description: Description: secure_connection2]
>

Re: Strange race-condition/possible bug in Subversion 1.7.0

Les Mikesell wrote on Wed, Oct 19, 2011 at 18:06:37 -0500:
> On Wed, Oct 19, 2011 at 3:58 PM, Harald Wilhelmi
>  wrote:
> >
> >    svn copy a b
> >    echo -n yyy >b
> >    svn commit -m 'c2' .
> >
> > Of cause I expect 'b' to contain 'yyy'. However sometimes it
> > contains 'xxx'. After this the repository is all consistent and fine
> > in my opinion (expect that 'a' has the unexpected content). However
> > the working copy looks strange. It behaves like that:
> >
> > 1) 'svn status' and 'svn diff' agree that there is no local change
> >   in 'b'.
> >
> > 2) If I just do a 'touch' on on 'b' without changing it's content,
> >   the svn command changes it's opinion. Now 'svn diff' and
> >   'svn status' agree that there is a local modification (xxx->yyy).
> >
> > Since I added the equivalent of a 'sleep 1' just after the 'svn copy'
> > I have not seen the issue again.
> >
> > Do you consider that a bug?
> 
> Svn is going to look at the timestamps (and maybe the length) on the
> pristine copy and your visible working copy file and if they match,
> assume there are no differences. So you need at least the timestamp
> resolution of your filesystem difference between the creation and
> change.

It's possible that we lack an svn_sleep_for_timestamps() call somewhere,
or that that call sleeps for less than the timestamp resolution of your
disk's fs.

Find the changed line numbers in a file

2011-10-20 Thread subhash_m


I want to know if there is any way I can find out the line numbers of the
changes made to a file. i.e. numbers of the lines in the modified file where
code is added or edited.

Thanks.
-- 
View this message in context: 
http://old.nabble.com/Find-the-changed-line-numbers-in-a-file-tp32688385p32688385.html
Sent from the Subversion Users mailing list archive at Nabble.com.

RE: Find the changed line numbers in a file

2011-10-20 Thread Cooke, Mark

> -Original Message-
> From: subhash_m [mailto:subhashsubh...@gmail.com] 
> Sent: 20 October 2011 10:49
> To: users@subversion.apache.org
> Subject: Find the changed line numbers in a file
> 
> 
> I want to know if there is any way I can find out the line 
> numbers of the
> changes made to a file. i.e. numbers of the lines in the 
> modified file where
> code is added or edited.
> 
> Thanks.

It is not clear what you want, do you want to do this from a script or just 
look at the file?

The 'blame' command will show a file and the version at which each line was 
changed morst recently and by whom:

http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.blame.html

~ mark c

Cooke, do you know how to using the get_log API to fetch subversion history along with path kind{file, directory}?

2011-10-20 Thread Yonggang Luo

If this is not possible, what's the fastest way to do that?
Thanks.


-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo

Re: How to use get_log along with path kind {file,directory}?

On Thu, Oct 20, 2011 at 09:01:52AM +0800, 罗勇刚(Yonggang Luo)  wrote:
> I didn't received the reply, so I repost it, because I am just
> subscribe to this list. Btw, can you be more specified, I didn't found
> the place how get_log along with path kind.

I assume your quesiton is about the API, rather than the command
line client, correct?

See the definition of svn_log_changed_path2_t:
http://people.apache.org/~hwright/svn/doc/api/trunk/structsvn__log__changed__path2__t.html
That data structure has the node kind.

You can get it via svn_ra_get_log2():
http://people.apache.org/~hwright/svn/doc/api/trunk/svn__ra_8h.html#a366d8ab12ae02fcade47bcbda7078f0a
from the changed_paths2 member of the svn_log_entry_t argument
http://people.apache.org/~hwright/svn/doc/api/trunk/structsvn__log__entry__t.html
which is passed to the log receiver you have to implement to use
svn_ra_get_log2(): 
http://people.apache.org/~hwright/svn/doc/api/trunk/svn__types_8h.html#afb30054d6301afbcd8b00d8dc11d7ddb

Hope this helps.

RE: Find the changed line numbers in a file

2011-10-20 Thread subhash_m


Hi Mark,
I want to do this from a script. Basically script should find out numbers of
the lines changed in the file. 

Thanks.


Cooke, Mark wrote:
> 
>> -Original Message-
>> From: subhash_m [mailto:subhashsubh...@gmail.com] 
>> Sent: 20 October 2011 10:49
>> To: users@subversion.apache.org
>> Subject: Find the changed line numbers in a file
>> 
>> 
>> I want to know if there is any way I can find out the line 
>> numbers of the
>> changes made to a file. i.e. numbers of the lines in the 
>> modified file where
>> code is added or edited.
>> 
>> Thanks.
> 
> It is not clear what you want, do you want to do this from a script or
> just look at the file?
> 
> The 'blame' command will show a file and the version at which each line
> was changed morst recently and by whom:
> 
> http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.blame.html
> 
> ~ mark c
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Find-the-changed-line-numbers-in-a-file-tp32688385p32688585.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: How to use get_log along with path kind {file,directory}?

2011-10-20 Thread Yonggang Luo

Thanks, that's impressive,
The type of the node, may be svn_node_unknown.: When this happened, is that
depending on the server or other condition?

*Are properties modified, may be svn_tristate_unknown. *Did old servers
support for this?
also with 
text_modified


>
> On Thu, Oct 20, 2011 at 09:01:52AM +0800, 罗勇刚(Yonggang Luo)  wrote:
> > I didn't received the reply, so I repost it, because I am just
> > subscribe to this list. Btw, can you be more specified, I didn't found
> > the place how get_log along with path kind.
>
> I assume your quesiton is about the API, rather than the command
> line client, correct?
>
> See the definition of svn_log_changed_path2_t:
>
> http://people.apache.org/~hwright/svn/doc/api/trunk/structsvn__log__changed__path2__t.html
> That data structure has the node kind.
>
> You can get it via svn_ra_get_log2():
>
> http://people.apache.org/~hwright/svn/doc/api/trunk/svn__ra_8h.html#a366d8ab12ae02fcade47bcbda7078f0a
> from the changed_paths2 member of the svn_log_entry_t argument
>
> http://people.apache.org/~hwright/svn/doc/api/trunk/structsvn__log__entry__t.html
> which is passed to the log receiver you have to implement to use
> svn_ra_get_log2():
> http://people.apache.org/~hwright/svn/doc/api/trunk/svn__types_8h.html#afb30054d6301afbcd8b00d8dc11d7ddb
>
> Hope this helps.
>


-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo

Re: Find the changed line numbers in a file

On Thu, Oct 20, 2011 at 03:24:55AM -0700, subhash_m wrote:
> 
> Hi Mark,
> I want to do this from a script. Basically script should find out numbers of
> the lines changed in the file. 

Install diffstat, and run 'svn diff -cN | diffstat'.

Example:
$ svn diff -c1186167 https://svn.apache.org/repos/asf | diffstat
 1.7.x/STATUS  |   11 
 1.7.x/subversion/libsvn_client/mergeinfo.c|   51 ++--
 1.7.x/subversion/tests/cmdline/mergeinfo_tests.py |   56 ++
 3 files changed, 103 insertions(+), 15 deletions(-)

Re: How to use get_log along with path kind {file,directory}?

On Thu, Oct 20, 2011 at 06:28:07PM +0800, 罗勇刚(Yonggang Luo)  wrote:
> Thanks, that's impressive,
> The type of the node, may be svn_node_unknown.: When this happened, is that
> depending on the server or other condition?

Maybe you are not allowed to see the path because of access
restrictions.

> *Are properties modified, may be svn_tristate_unknown.

Again, 'unknown' means the server is not allowed to tell you
because the administrator configured restrictive access rights
for the path.

> *Did old servers support for this?

Only 1.6 and better support svn_log_changed_path2_t.
Older servers will return svn_log_changed_path_t, which doesn't
have the node kind:
http://people.apache.org/~hwright/svn/doc/api/trunk/structsvn__log__changed__path__t.html

Re: Find the changed line numbers in a file

2011-10-20 Thread subhash_m


Thanks for diffstat suggestion. But I am on Windows. :(


Stefan Sperling-7 wrote:
> 
> On Thu, Oct 20, 2011 at 03:24:55AM -0700, subhash_m wrote:
>> 
>> Hi Mark,
>> I want to do this from a script. Basically script should find out numbers
>> of
>> the lines changed in the file. 
> 
> Install diffstat, and run 'svn diff -cN | diffstat'.
> 
> Example:
> $ svn diff -c1186167 https://svn.apache.org/repos/asf | diffstat
>  1.7.x/STATUS  |   11 
>  1.7.x/subversion/libsvn_client/mergeinfo.c|   51
> ++--
>  1.7.x/subversion/tests/cmdline/mergeinfo_tests.py |   56
> ++
>  3 files changed, 103 insertions(+), 15 deletions(-)
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Find-the-changed-line-numbers-in-a-file-tp32688385p32688730.html
Sent from the Subversion Users mailing list archive at Nabble.com.

How to use get_log along with path kind {file,directory}?

2011-10-20 Thread Yonggang Luo

在 2011年10月20日星期四，Stefan Sperling 写道：

> On Thu, Oct 20, 2011 at 06:28:07PM +0800, 罗勇刚(Yonggang Luo)  wrote:
> > Thanks, that's impressive,
> > The type of the node, may be svn_node_unknown.: When this happened, is
> that
> > depending on the server or other condition?
>
> Maybe you are not allowed to see the path because of access
> restrictions.
>
> > *Are properties modified, may be svn_tristate_unknown.
>
> Again, 'unknown' means the server is not allowed to tell you
> because the administrator configured restrictive access rights
> for the path.
>
> > *Did old servers support for this?
>
> Only 1.6 and better support svn_log_changed_path2_t.
> Older servers will return svn_log_changed_path_t, which doesn't
> have the node kind:
>
> http://people.apache.org/~hwright/svn/doc/api/trunk/structsvn__log__changed__path__t.html

So that's totally depending on the server, on more question, is that means
properties modified and text modified only support by server newer than or
just be subversion server 1.7?
If the server restricted me to get the kind, what's the fastest way to fetch
it in other way?


-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo

Re: How to use get_log along with path kind {file,directory}?

On Thu, Oct 20, 2011 at 06:57:47PM +0800, 罗勇刚(Yonggang Luo)  wrote:
> 在 2011年10月20日星期四，Stefan Sperling 写道：
> > Only 1.6 and better support svn_log_changed_path2_t.
> > Older servers will return svn_log_changed_path_t, which doesn't
> > have the node kind:
> >
> > http://people.apache.org/~hwright/svn/doc/api/trunk/structsvn__log__changed__path__t.html
> 
> So that's totally depending on the server, on more question, is that means
> properties modified and text modified only support by server newer than or
> just be subversion server 1.7?

Yes.

With older servers, you can try to list the node to get its kind.
See these links:
http://people.apache.org/~hwright/svn/doc/api/trunk/structsvn__dirent__t.html
http://people.apache.org/~hwright/svn/doc/api/trunk/group__List.html#ga3ac4238fdc4d135798fdcce31bff829a
http://people.apache.org/~hwright/svn/doc/api/trunk/group__List.html#gad34331c2f22f8b5ee906c4abff0866d0

> If the server restricted me to get the kind, what's the fastest way to fetch
> it in other way?

No. The whole point of authorization is to prevent unauthorized
clients from getting this information. If you can work around it
you have found a security hole.

Re: How to use get_log along with path kind {file,directory}?

On Thu, Oct 20, 2011 at 01:09:41PM +0200, Stefan Sperling wrote:
> On Thu, Oct 20, 2011 at 06:57:47PM +0800, 罗勇刚(Yonggang Luo)  wrote:
> > If the server restricted me to get the kind, what's the fastest way to fetch
> > it in other way?
> 
> No. The whole point of authorization is to prevent unauthorized
> clients from getting this information. If you can work around it
> you have found a security hole.

To put it another way: The fastest way of getting the node
kind of an authz-restricted path is to ask the server administrator
or some other user who has access to the path :)

Re: Cooke, do you know how to using the get_log API to fetch subversion history along with path kind{file, directory}?

Do not email individual people.  They are volunteers and it's rude to
demand answers from them, especially when they've already seen your list
posts.

Re: Find the changed line numbers in a file

Then install diffstat.exe and repeat what Stefan said :)

It's probably in the diffutils or diffstat package on gnuwin32.sf.net or
a similar place.

subhash_m wrote on Thu, Oct 20, 2011 at 03:56:41 -0700:
> 
> Thanks for diffstat suggestion. But I am on Windows. :(
> 
> 
> Stefan Sperling-7 wrote:
> > 
> > On Thu, Oct 20, 2011 at 03:24:55AM -0700, subhash_m wrote:
> >> 
> >> Hi Mark,
> >> I want to do this from a script. Basically script should find out numbers
> >> of
> >> the lines changed in the file. 
> > 
> > Install diffstat, and run 'svn diff -cN | diffstat'.
> > 
> > Example:
> > $ svn diff -c1186167 https://svn.apache.org/repos/asf | diffstat
> >  1.7.x/STATUS  |   11 
> >  1.7.x/subversion/libsvn_client/mergeinfo.c|   51
> > ++--
> >  1.7.x/subversion/tests/cmdline/mergeinfo_tests.py |   56
> > ++
> >  3 files changed, 103 insertions(+), 15 deletions(-)
> > 
> > 
> 
> -- 
> View this message in context: 
> http://old.nabble.com/Find-the-changed-line-numbers-in-a-file-tp32688385p32688730.html
> Sent from the Subversion Users mailing list archive at Nabble.com.
>

Subversion Exception

2011-10-20 Thread Denis S. Abramov

---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

(users@subversion.apache.org)

with as much information as possible about what

you were trying to do.

But please first search the mailing list archives for the error message

to avoid reporting the same problem repeatedly.

You can find the mailing list archives at

http://subversion.apache.org/mailing-lists.html

 

Subversion reported the following

(you can copy the content of this dialog

to the clipboard using Ctrl-C):

 

In file

 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\lib
svn_wc\wc_db_pristine.c'

 line 228: assertion failed (sha1_checksum != NULL)

---

ОК   

---

 

Thank you,

Denis

[no subject]

2011-10-20 Thread BOS - Alexander Dickbauer

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c'
line 672: assertion failed (checksum != NULL)
---
OK



Beste Grüße aus Kremsmünster

Alexander Dickbauer
BOS EDV GmbH & CoKG
Bad Haller Straße 23 | 4550 Kremsmünster | ATU24023303
Tel.   +43 (0) 7583 / 55 66-135   |   Fax.  +43 (0) 7583 / 55 66 30
dickbauer.alexan...@bos.at   |   
www.bos.at  |  www.digitacho.at

RE: Help! Subversion Exception!

2011-10-20 Thread Bob Archer

> 
> But if i have a lot of different local modifications in sources, you propose 
> me
> to checkout??? You are crazy?

You tried to upgrade a working copy with pending changes in it? Are you crazy?

BOb

RE: Merge strategies?

2011-10-20 Thread Bob Archer

> On 19.10.2011 14:00, Stefan Sperling wrote:
> > On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:
> >> What about my other fears, bloated svn:mergeinfo
> >
> > The entire svn:mergeinfo property is stored in RAM and parsed from
> > string form into a data structure (nested hash table) before it is used.
> > With modern hardware, you'd have to hit svn:mergeinfo sizes that go
> > into hundreds of megabytes before you'll notice any slowdown.
> >
> 
> Hm, but this parsing occurs on every invocation of "svn.exe", or I'm missing
> something?
> 
> >> and svn:mergeinfo conflicts?
> >
> > Have you ever seen a mergeinfo conflict? I haven't.
> >
> 
> I haven't, too, because everyone uses --ignore-ancestry here ;-)

We've moved away from using trunk to simplify our merging and eliminate cyclic 
merges.

We have something like:

Project
   /Version1
   /Version2
   /Branches
  /Feature1
  /Feature2
   /Tags
  /Release1
  /Release2

We release from the VersionX path. When we start on a new release a new 
VersionX path is created by copying (branching) from the previous version. 
Feature branches are created from a VersionX path then reintegrated when the 
features is complete. We only use feature branches for stuff that will take 
more than on sprint. 

The above has really helped the organization of our build server since we don't 
have to constantly wonder what version is in progress on trunk.

If we fix an issue in a specific version those changes are merged up into each 
version as needed. We generally don't deal with more than 3 versions at a time 
so the "up merging" is rarely need beyond 2 merges.

It's not perfect but it works much better for us than stable trunk, branch for 
release was working. And all the devs easily understand what it is what path 
when they browse the repo.

BOb

revision number offset

2011-10-20 Thread morten bjoernsvik

Hi All

I'm a very pleased svn user, but I have this little issue.

In many cases with small projects I move the repository around
(like we have been used to with git)

svnadmin dump  | bzip2 > repository_revXX.svndump.bz2

and then:
svnadmin create 
bzip2 -dc repository_revXX.svndump.bz2 | svnadmin load 

This works fine up to around 100-150 revisions, then it becomes slow and I
delete the old repository and start a completely new with the latest revisions.


But I'm unable to keep the revision number, I like my new commit to start with
rev XX+1 not 1. Why cant I start on any revision number I like?

Even if I use the -rXX for dump it is converted to start on 1 when I load.

The only solution I've seen is to add XX empty revisions. But this does not 
look good
when revisison becomes very high.


Is there a solution or workaround?

Thanks


--
Morten Bjoernsvik, Oslo, Norway

Re: Merge strategies?

2011-10-20 Thread Andrey Paramonov


On 20.10.2011 17:55, Bob Archer wrote:

On 19.10.2011 14:00, Stefan Sperling wrote:

On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:

What about my other fears, bloated svn:mergeinfo


The entire svn:mergeinfo property is stored in RAM and parsed from
string form into a data structure (nested hash table) before it is used.
With modern hardware, you'd have to hit svn:mergeinfo sizes that go
into hundreds of megabytes before you'll notice any slowdown.



Hm, but this parsing occurs on every invocation of "svn.exe", or I'm missing
something?


and svn:mergeinfo conflicts?


Have you ever seen a mergeinfo conflict? I haven't.



I haven't, too, because everyone uses --ignore-ancestry here ;-)


We've moved away from using trunk to simplify our merging and eliminate cyclic 
merges.

We have something like:

Project
/Version1
/Version2
/Branches
   /Feature1
   /Feature2
/Tags
   /Release1
   /Release2

We release from the VersionX path. When we start on a new release a new 
VersionX path is created by copying (branching) from the previous version. 
Feature branches are created from a VersionX path then reintegrated when the 
features is complete. We only use feature branches for stuff that will take 
more than on sprint.

The above has really helped the organization of our build server since we don't 
have to constantly wonder what version is in progress on trunk.

If we fix an issue in a specific version those changes are merged up into each version as 
needed. We generally don't deal with more than 3 versions at a time so the "up 
merging" is rarely need beyond 2 merges.

It's not perfect but it works much better for us than stable trunk, branch for 
release was working. And all the devs easily understand what it is what path 
when they browse the repo.

BOb


Thank you for your answer. A couple of questions:

1) Do you usually merge upstream or downstream?
2) Do you set mergeinfo when merging downstream?
3) Do you set mergeinfo when merging upstream?
4) Do you set mergeinfo when merging from feature branch?

Best wishes,
Andrey Paramonov

Re: revision number offset

2011-10-20 Thread Andy Levy

On Thu, Oct 20, 2011 at 10:08, morten bjoernsvik
 wrote:
> Hi All
> I'm a very pleased svn user, but I have this little issue.
> In many cases with small projects I move the repository around
> (like we have been used to with git)
> svnadmin dump  | bzip2 > repository_revXX.svndump.bz2
> and then:
> svnadmin create 
> bzip2 -dc repository_revXX.svndump.bz2 | svnadmin load 
> This works fine up to around 100-150 revisions, then it becomes slow and I
> delete the old repository and start a completely new with the latest
> revisions.
>
> But I'm unable to keep the revision number, I like my new commit to start
> with
> rev XX+1 not 1. Why cant I start on any revision number I like?

Because the revision number is a running count of the number of
changes committed to the repository. When you create a new, empty
repository you start all over again.

> Even if I use the -rXX for dump it is converted to start on 1 when I load.
> The only solution I've seen is to add XX empty revisions. But this does not
> look good
> when revisison becomes very high.

That is the only way to force Subversion to "start" your revision
numbers at something other than 0.

> Is there a solution or workaround?

The solution is to not keep moving your repository around they way you
are. Why do you feel you need to do this? Are svnsync mirrors not
sufficient for your usage (if they'd even be applicable to your use
case)? Perhaps a DVCS like hg or git *is* more appropriate for you
than Subversion?

RE: Help! Subversion Exception!

2011-10-20 Thread James French

Upgrading to svn 1.7 whose principal feature is a major change to the working 
copy, with local mods, is just plain dumb.

From: Igor d [mailto:igoro...@gmail.com]
Sent: 18 October 2011 15:20
To: Igor d; users@subversion.apache.org
Subject: Re: Help! Subversion Exception!

But if i have a lot of different local modifications in sources, you propose me 
to checkout??? You are crazy?

workqueue.c line 672: assertion failed (checksum !=NULL)

2011-10-20 Thread Michael Bryans

Trying to update local folder and get this:

[cid:image001.png@01CC8F10.F73CD6F0]

Cleanup fails.  Updates will not work stating a previous process is not 
complete.  It never completes.  Stuck!

Regards,
Michael Bryans

<>

Re: workqueue.c line 672: assertion failed (checksum !=NULL)

On Thu, Oct 20, 2011 at 02:15:28PM +, Michael Bryans wrote:
> Trying to update local folder and get this:
> 
> [cid:image001.png@01CC8F10.F73CD6F0]
> 
> Cleanup fails.  Updates will not work stating a previous process is not 
> complete.  It never completes.  Stuck!
> 

Get a new checkout. This problem will be fixed in 1.7.1 which will
be released in 4 days or so.

Vedr: revision number offset

2011-10-20 Thread morten bjoernsvik

Thanks Andy

Most of the servers I work on do not have internet access, only citrix/cisco 
vpn via
putty and openscp. So I can only scp a file back and forth, but no ssh+svn.

Git is fine, but the support for it in komodo(our IDE) is poor and we have
beeen using svn for years. 

I also like to clean up repositores from time to time, aka
a svnadmin -rXX:YY dump then delete and load to only save the latest 10 
revisions and drop the rest.

But if others see the revison-number being lower they believe it to be older 
code.

If only the revision number was kept this would have worked.

Thanks

--
MortenB

Fra: Andy Levy 
Til: morten bjoernsvik 
Kopi: "users@subversion.apache.org" 
Sendt: Torsdag, 20. oktober 2011 16.26
Emne: Re: revision number offset

On Thu, Oct 20, 2011 at 10:08, morten bjoernsvik
 wrote:
> Hi All
> I'm a very pleased svn user, but I have this little issue.
> In many cases with small projects I move the repository around
> (like we have been used to with git)
> svnadmin dump  | bzip2 > repository_revXX.svndump.bz2
> and then:
> svnadmin create 
> bzip2 -dc repository_revXX.svndump.bz2 | svnadmin load 
> This works fine up to around 100-150 revisions, then it becomes slow and I
> delete the old repository and start a completely new with the latest
> revisions.
>
> But I'm unable to keep the revision number, I like my new commit to start
> with
> rev XX+1 not 1. Why cant I start on any revision number I like?

Because the revision number is a running count of the number of
changes committed to the repository. When you create a new, empty
repository you start all over again.

> Even if I use the -rXX for dump it is converted to start on 1 when I load.
> The only solution I've seen is to add XX empty revisions. But this does not
> look good
> when revisison becomes very high.

That is the only way to force Subversion to "start" your revision
numbers at something other than 0.

> Is there a solution or workaround?

The solution is to not keep moving your repository around they way you
are. Why do you feel you need to do this? Are svnsync mirrors not
sufficient for your usage (if they'd even be applicable to your use
case)? Perhaps a DVCS like hg or git *is* more appropriate for you
than Subversion?

Re: Help! Subversion Exception!

2011-10-20 Thread Andreas Krey

On Thu, 20 Oct 2011 09:43:58 +, Bob Archer wrote:
...
> You tried to upgrade a working copy with pending changes in it? Are you crazy?

I'm not aware that you can run two tortoises in parallel, which means
you have no chance of not upgrading an old WC if you want to update
it -> all of our WC have to be clean when upgrading, which would
be pretty hard on me.

Andreas

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

Re: Help! Subversion Exception!

Bob Archer wrote on Thu, Oct 20, 2011 at 09:43:58 -0400:
> > 
> > But if i have a lot of different local modifications in sources, you 
> > propose me
> > to checkout??? You are crazy?
> 
> You tried to upgrade a working copy with pending changes in it? Are you crazy?

Updating a working copy that contains local mods is a supported scenario.

Upgrading a working copy that requires cleanup is not.

RE: Merging to branches error

2011-10-20 Thread Dimitry Gavrilov

Hi Daniel,

Thank you for the reply.

I tried to completely reinstall tortoise 1.7 and checkout my subversions again 
and it seems to work now.

The problem was when I upgraded old subversion structure from 1.6 to 1.7.

I will let you know if the problem appears again.


Dimitry Gavrilov
Senior Lead Engineer




-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: Thursday, October 20, 2011 12:23 AM
To: Dimitry Gavrilov
Cc: users@subversion.apache.org
Subject: Re: Merging to branches error

Dimitry Gavrilov wrote on Wed, Oct 19, 2011 at 18:27:11 +:
> Hi,
> 
> I installed tortoise 1.7 64-bit version on Win 7.
> 
> I am getting the below error constantly while trying to commit or merge to 
> branches.
> 
> What should I do?
> 

That looks like a new bug, thanks.

Do you know how to reproduce this error, preferably starting from an empty 
repository or a publicly readable one?

> ---
> Subversion Exception!
> ---
> Subversion encountered a serious problem.
> Please take the time to report this on the Subversion mailing list
> (users@subversion.apache.org)
> with as much information as possible about what you were trying to do.
> But please first search the mailing list archives for the error 
> message to avoid reporting the same problem repeatedly.
> You can find the mailing list archives at 
> http://subversion.apache.org/mailing-lists.html
> 
> Subversion reported the following
> (you can copy the content of this dialog to the clipboard using 
> Ctrl-C):
> 
> In file
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\wc_db.c'
> line 7393: internal malfunction
> ---
> OK
> ---
> 
> Dimitry Gavrilov
> Senior Lead Engineer
> 
> [Description: Description: secure_connection2]
>

Re: Merging to branches error

Not surprised; the problem is most likely related to the state of your
working copies and the history of the branches you were merging.  Was
there anything noteworthy about either of those?

Dimitry Gavrilov wrote on Thu, Oct 20, 2011 at 16:58:58 +:
> Hi Daniel,
> 
> Thank you for the reply.
> 
> I tried to completely reinstall tortoise 1.7 and checkout my subversions 
> again and it seems to work now.
> 
> The problem was when I upgraded old subversion structure from 1.6 to 1.7.
> 
> I will let you know if the problem appears again.
> 
> 
> Dimitry Gavrilov
> Senior Lead Engineer
> 
> 
> 
> 
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
> Sent: Thursday, October 20, 2011 12:23 AM
> To: Dimitry Gavrilov
> Cc: users@subversion.apache.org
> Subject: Re: Merging to branches error
> 
> Dimitry Gavrilov wrote on Wed, Oct 19, 2011 at 18:27:11 +:
> > Hi,
> > 
> > I installed tortoise 1.7 64-bit version on Win 7.
> > 
> > I am getting the below error constantly while trying to commit or merge to 
> > branches.
> > 
> > What should I do?
> > 
> 
> That looks like a new bug, thanks.
> 
> Do you know how to reproduce this error, preferably starting from an empty 
> repository or a publicly readable one?
> 
> > ---
> > Subversion Exception!
> > ---
> > Subversion encountered a serious problem.
> > Please take the time to report this on the Subversion mailing list
> > (users@subversion.apache.org)
> > with as much information as possible about what you were trying to do.
> > But please first search the mailing list archives for the error 
> > message to avoid reporting the same problem repeatedly.
> > You can find the mailing list archives at 
> > http://subversion.apache.org/mailing-lists.html
> > 
> > Subversion reported the following
> > (you can copy the content of this dialog to the clipboard using 
> > Ctrl-C):
> > 
> > In file
> > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\wc_db.c'
> > line 7393: internal malfunction
> > ---
> > OK
> > ---
> > 
> > Dimitry Gavrilov
> > Senior Lead Engineer
> > 
> > [Description: Description: secure_connection2]
> > 
> 
>

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 11:38 AM, Daniel Shahaf  wrote:
> Bob Archer wrote on Thu, Oct 20, 2011 at 09:43:58 -0400:
>> >
>> > But if i have a lot of different local modifications in sources, you 
>> > propose me
>> > to checkout??? You are crazy?
>>
>> You tried to upgrade a working copy with pending changes in it? Are you 
>> crazy?
>
> Updating a working copy that contains local mods is a supported scenario.
>
> Upgrading a working copy that requires cleanup is not.

How is a user supposed to know if his working copy requires cleanup?
And how should it be handled in multiuser scenarios where the svn
binaries are managed and updated by someone other than the people who
may have active working copies?

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

Re: Help! Subversion Exception!

Les Mikesell wrote on Thu, Oct 20, 2011 at 12:20:16 -0500:
> On Thu, Oct 20, 2011 at 11:38 AM, Daniel Shahaf  
> wrote:
> > Bob Archer wrote on Thu, Oct 20, 2011 at 09:43:58 -0400:
> >> >
> >> > But if i have a lot of different local modifications in sources, you 
> >> > propose me
> >> > to checkout??? You are crazy?
> >>
> >> You tried to upgrade a working copy with pending changes in it? Are you 
> >> crazy?
> >
> > Updating a working copy that contains local mods is a supported scenario.
> >
> > 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.

> And how should it be handled in multiuser scenarios where the svn
> binaries are managed and updated by someone other than the people who
> may have active working copies?
> 

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

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

Re: mergeinfo marked not inheritable on sparse checkout

2011-10-20 Thread Douglas Wilson


On Oct 19, 11:06 am, Douglas Wilson  wrote:
> On Oct 19, 12:29 am, Johan Corveleyn  wrote:
>
> > There were a lot of merge-tracking improvements and bugfixes in 1.7,
> > but I'm not sure if this particular issue has been addressed. See 
> > http://subversion.apache.org/docs/release-notes/1.7.html#merge-tracki

I checked, there doesn't seem to be anything that specifically
addressed this sort of situation.

Re: mergeinfo marked not inheritable on sparse checkout

On Thu, Oct 20, 2011 at 10:35:41AM -0700, Douglas Wilson wrote:
> 
> On Oct 19, 11:06 am, Douglas Wilson  wrote:
> > On Oct 19, 12:29 am, Johan Corveleyn  wrote:
> >
> > > There were a lot of merge-tracking improvements and bugfixes in 1.7,
> > > but I'm not sure if this particular issue has been addressed. See 
> > > http://subversion.apache.org/docs/release-notes/1.7.html#merge-tracki
> 
> I checked, there doesn't seem to be anything that specifically
> addressed this sort of situation.

Which version of SVN are you running when you hit the problem
you described in your first post? 1.6 or 1.7?

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 12:26 PM, Daniel Shahaf  wrote:
>
>>
>> How is a user supposed to know if his working copy requires cleanup?
>
> You'll get E155021.

But only after it is too late, right?   Are there any tools to check
this that don't overwrite the versions that might have still been able
to do something with the existing working copy?

>> And how should it be handled in multiuser scenarios where the svn
>> binaries are managed and updated by someone other than the people who
>> may have active working copies?
>>
>
> Have users always run 'svn cleanup' before they leave for the night on
> any wc's that they ^C'd during the day?

Is that documented somewhere?

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

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 12:47:25PM -0500, Les Mikesell wrote:
> On Thu, Oct 20, 2011 at 12:26 PM, Daniel Shahaf  
> wrote:
> >
> >>
> >> How is a user supposed to know if his working copy requires cleanup?
> >
> > You'll get E155021.
> 
> But only after it is too late, right?   Are there any tools to check
> this that don't overwrite the versions that might have still been able
> to do something with the existing working copy?

If a working copy requires cleanup, a 1.6 client that touches the
working copy will tell you so. A 1.7 client will refuse to upgrade it.

> >> And how should it be handled in multiuser scenarios where the svn
> >> binaries are managed and updated by someone other than the people who
> >> may have active working copies?
> >>
> >
> > Have users always run 'svn cleanup' before they leave for the night on
> > any wc's that they ^C'd during the day?
> 
> Is that documented somewhere?

I don't think Daniel is right here. Generally, you don't need to run
'svn cleanup' just because you cancel some SVN operation with Ctrl-C.
You need to run it after an svn client has crashed or for some other
reasons failed to clean up its locks or run pending changes from the
working copy's work queue.

Re: Help! Subversion Exception!

Les Mikesell wrote on Thu, Oct 20, 2011 at 12:47:25 -0500:
> On Thu, Oct 20, 2011 at 12:26 PM, Daniel Shahaf  
> wrote:
> >
> >>
> >> How is a user supposed to know if his working copy requires cleanup?
> >
> > You'll get E155021.
> 
> But only after it is too late, right?   Are there any tools to check
> this that don't overwrite the versions that might have still been able
> to do something with the existing working copy?
> 

I don't understand the question.  As a rule, when upgrade fails the
working copy remains usable by the older version of svn.

> >> And how should it be handled in multiuser scenarios where the svn
> >> binaries are managed and updated by someone other than the people who
> >> may have active working copies?
> >>
> >
> > Have users always run 'svn cleanup' before they leave for the night on
> > any wc's that they ^C'd during the day?
> 
> Is that documented somewhere?
> 

1.7 release notes.

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 12:51 PM, Daniel Shahaf  wrote:

>> >> How is a user supposed to know if his working copy requires cleanup?
>> >
>> > You'll get E155021.
>>
>> But only after it is too late, right?   Are there any tools to check
>> this that don't overwrite the versions that might have still been able
>> to do something with the existing working copy?
>>
>
> I don't understand the question.  As a rule, when upgrade fails the
> working copy remains usable by the older version of svn.

Which you won't have any longer  if you or your system administrator
has updated the programs.

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

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 01:01:32PM -0500, Les Mikesell wrote:
> On Thu, Oct 20, 2011 at 12:51 PM, Daniel Shahaf  
> wrote:
> > I don't understand the question.  As a rule, when upgrade fails the
> > working copy remains usable by the older version of svn.
> 
> Which you won't have any longer  if you or your system administrator
> has updated the programs.

Well, this is quite an obvious and known issue. The release notes clearly
say that newer clients do not work with older working copies.

SVN Exception

2011-10-20 Thread Angel Raffety

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
'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))
---
OK
---

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 1:07 PM, Stefan Sperling  wrote:
>
>> > I don't understand the question.  As a rule, when upgrade fails the
>> > working copy remains usable by the older version of svn.
>>
>> Which you won't have any longer  if you or your system administrator
>> has updated the programs.
>
> Well, this is quite an obvious and known issue. The release notes clearly
> say that newer clients do not work with older working copies.

Perhaps it is obvious and known to you.  I think the number of error
reports on the list indicates that the scenarios that cause errors are
not generally well understood. And, I'd guess that the current
updaters are mostly self-sufficient developers working on personal
machines and we'll see worse when the packaged updates for popular
multiuser systems start rolling out. That is, OS system updates done
mostly-automatically by an administrator will replace the binaries
without an easy way back, and some users' working copies will upgrade
successfully and some won't.  In that scenario, should the unlucky
user try to install his own copy of the old binaries if he can find
them?

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

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 01:30:34PM -0500, Les Mikesell wrote:
> On Thu, Oct 20, 2011 at 1:07 PM, Stefan Sperling  wrote:
> >
> >> > I don't understand the question.  As a rule, when upgrade fails the
> >> > working copy remains usable by the older version of svn.
> >>
> >> Which you won't have any longer  if you or your system administrator
> >> has updated the programs.
> >
> > Well, this is quite an obvious and known issue. The release notes clearly
> > say that newer clients do not work with older working copies.
> 
> Perhaps it is obvious and known to you.  I think the number of error
> reports on the list indicates that the scenarios that cause errors are
> not generally well understood. And, I'd guess that the current
> updaters are mostly self-sufficient developers working on personal
> machines and we'll see worse when the packaged updates for popular
> multiuser systems start rolling out. That is, OS system updates done
> mostly-automatically by an administrator will replace the binaries
> without an easy way back, and some users' working copies will upgrade
> successfully and some won't.  In that scenario, should the unlucky
> user try to install his own copy of the old binaries if he can find
> them?

The unlucky user should simply get a new working copy.
Working copies are and have always been considered disposable.

Re: Help! Subversion Exception!

Stefan Sperling wrote on Thu, Oct 20, 2011 at 20:07:17 +0200:
> On Thu, Oct 20, 2011 at 01:01:32PM -0500, Les Mikesell wrote:
> > On Thu, Oct 20, 2011 at 12:51 PM, Daniel Shahaf  
> > wrote:
> > > I don't understand the question.  As a rule, when upgrade fails the
> > > working copy remains usable by the older version of svn.
> > 
> > Which you won't have any longer  if you or your system administrator
> > has updated the programs.
> 
> Well, this is quite an obvious and known issue. The release notes clearly
> say that newer clients do not work with older working copies

that require cleanup

> .

Re: Help! Subversion Exception!

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

Re: Help! Subversion Exception!

2011-10-20 Thread Philip Martin

Les Mikesell  writes:

> Perhaps it is obvious and known to you.  I think the number of error
> reports on the list indicates that the scenarios that cause errors are
> not generally well understood.

The error in this case:

line 1935: assertion failed (svn_checksum_match(entry_md5_checksum, 
found_md5_checksum))

indicates that the working copy is corrupt.  This is not a problem that
can be solved by running cleanup.  It's possible that it could be solved
in other ways (by running "svn up -r0" on the affected files perhaps, or
"rm -rf on a subdir) but it's still risky to upgrade a corrupt working
copy as we don't know what other corruption is present.

It's possible that the corruption has lain dormant in the 1.6 working
copy for some time, the corrupt checksum will only be reconised when an
update or commit attempts to explicitly modify the file with a problem.
Other 1.6 operations won't examine the corrupt checksum.  However the
1.7 upgrade has to recalculate checksums for all the files so it falls
over on such cases.

One of the things we would like to do is verify that this really is
corruption but that is hard because the error message isn't very good
(1.7.1 will do better--it will tell you which file has the problem) and
our users don't always have the tools to do it.  We need sombody capable
of debugging the assertion to identify the file, and then checking the
stored checksum against the actual checksum.  Alternatively somebody who
can validate all the the checksums in the working copy to see if any are
wrong.  Or somebody who is prepared to send their working copy to me so
that I can do it.

-- 
Philip

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 1:33 PM, Stefan Sperling  wrote:
>
> The unlucky user should simply get a new working copy.
> Working copies are and have always been considered disposable.

So why bother to upgrade them at all if success is unimportant?

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

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 01:53:19PM -0500, Les Mikesell wrote:
> On Thu, Oct 20, 2011 at 1:33 PM, Stefan Sperling  wrote:
> >
> > The unlucky user should simply get a new working copy.
> > Working copies are and have always been considered disposable.
> 
> So why bother to upgrade them at all if success is unimportant?

You misunderstood what I meant.

Most reports about failed upgrades so far were due to *corrupt* 1.6
working copies. We cannot safely upgrade them, see Philip's reply.

We do care about upgrading good 1.6 working copies, and have
fixed several bugs in 1.7.1 based on the reports we received.

Version 1.7.1
(24 Oct 2011, from /branches/1.7.x)
http://svn.apache.org/repos/asf/subversion/tags/1.7.1

  User-visible changes:
   [...]
   * fix WC upgrade with replaced nodes in edge-case (issue #4033)
   [...]
   * fix upgrading of WCs containing authz-restricted dirs (r1185738)
   [...]
   * fix 'checksum != NULL' assertions in some upgraded WCs (r1177732)
   [...]

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 1:58 PM, Stefan Sperling  wrote:

>> > The unlucky user should simply get a new working copy.
>> > Working copies are and have always been considered disposable.
>>
>> So why bother to upgrade them at all if success is unimportant?
>
> You misunderstood what I meant.

No, I'm just being difficult because you didn't seem to care about the
potential for losing uncommitted changes.

> Most reports about failed upgrades so far were due to *corrupt* 1.6
> working copies. We cannot safely upgrade them, see Philip's reply.
>
> We do care about upgrading good 1.6 working copies, and have
> fixed several bugs in 1.7.1 based on the reports we received.

Is there any tool that you can run to do a corruption check on a 1.6
working copy that does not overwrite a needed 1.6 program and does not
actually do the upgrade?  It seems like it would be a good thing to
know whether or not you were ready to upgrade.

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

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 02:03:58PM -0500, Les Mikesell wrote:
> On Thu, Oct 20, 2011 at 1:58 PM, Stefan Sperling  wrote:
> 
> >> > The unlucky user should simply get a new working copy.
> >> > Working copies are and have always been considered disposable.
> >>
> >> So why bother to upgrade them at all if success is unimportant?
> >
> > You misunderstood what I meant.
> 
> No, I'm just being difficult because you didn't seem to care about the
> potential for losing uncommitted changes.

There are tools to merge local changes over from a corrupt working copy
to a new working copy. Some have been mentioned recently in the various
"help! expection" threads.  I'd use rsync.

> > Most reports about failed upgrades so far were due to *corrupt* 1.6
> > working copies. We cannot safely upgrade them, see Philip's reply.
> >
> > We do care about upgrading good 1.6 working copies, and have
> > fixed several bugs in 1.7.1 based on the reports we received.
> 
> Is there any tool that you can run to do a corruption check on a 1.6
> working copy that does not overwrite a needed 1.6 program and does not
> actually do the upgrade?

Not that I know of, unfortunately.
How to detect corruption also depends on the kind of corruption at hand.

> It seems like it would be a good thing to
> know whether or not you were ready to upgrade.

If in doubt, commit local changes before upgrading to 1.7.
If your admin took 1.6 away from you prematurely, complain to him.

I don't think this is a big problem because there are ways to cope.
And the benefits from updating from 1.6 to 1.7 are worth the trouble
in any case.

However, bugs that prevent good working copies from upgrading are bad
and need to be fixed.

Does this make sense?

Re: Help! Subversion Exception!

2011-10-20 Thread Dave Huang

On Oct 20, 2011, at 2:03 PM, Les Mikesell wrote:
> No, I'm just being difficult because you didn't seem to care about the
> potential for losing uncommitted changes.

Why would you lose them? The upgrade process doesn't delete or modify your 
files, right? It only changes the contents of the .svn dir.

As has been posted (I don't remember which thread; probably not this one, but 
in one of the numerous threads about this issue), you can just use some sort of 
diff utility to copy your uncommitted changes to a clean checkout. If you don't 
have any uncommitted deletes, you could even just delete all .svn dirs in your 
broken WC, then copy what's left on top of the fresh WC. Something to the 
effect of:

cd $broken_wc; find . -name .svn | xargs rm -r; pax -rw . $fresh_wc

(untested, but you get the idea)
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

Re: Help! Subversion Exception!

Les Mikesell wrote on Thu, Oct 20, 2011 at 14:03:58 -0500:
> Is there any tool that you can run to do a corruption check on a 1.6
> working copy that does not overwrite a needed 1.6 program and does not
> actually do the upgrade?  It seems like it would be a good thing to
> know whether or not you were ready to upgrade.

tar(1)

Re: Help! Subversion Exception!

Andreas Krey wrote on Thu, Oct 20, 2011 at 20:38:58 +0200:
> On Thu, 20 Oct 2011 19:26:06 +, Daniel Shahaf wrote:
> > Have users always run 'svn cleanup' before they leave for the night on
> > 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.
> 

Ahem, that's exactly how has been working, since years.

> 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

Personally I prefer ^\ (SIGQUIT) in that case.  As Stefan said, though,
it is fatal signals (SIGQUIT, SIGKILL, SIGSEGV) --- not SIGINT (^C) ---
that typically cause 'svn cleanup' to be required.

Re: Help! Subversion Exception!

On Thu, Oct 20, 2011 at 2:18 PM, Dave Huang  wrote:
>
> On Oct 20, 2011, at 2:03 PM, Les Mikesell wrote:
>> No, I'm just being difficult because you didn't seem to care about the
>> potential for losing uncommitted changes.
>
> Why would you lose them? The upgrade process doesn't delete or modify your 
> files, right? It only changes the contents of the .svn dir.
>
> As has been posted (I don't remember which thread; probably not this one, but 
> in one of the numerous threads about this issue), you can just use some sort 
> of diff utility to copy your uncommitted changes to a clean checkout. If you 
> don't have any uncommitted deletes, you could even just delete all .svn dirs 
> in your broken WC, then copy what's left on top of the fresh WC. Something to 
> the effect of:
>
> cd $broken_wc; find . -name .svn | xargs rm -r; pax -rw . $fresh_wc
>
> (untested, but you get the idea)

I'd sort of expect an rsync with the -C option to get it mostly right.
 But then again I would have expected a 1.6 working copy that was
working with 1.6 programs to not be considered corrupt by 1.7 so I'm
not sure how you'd know what to propagate over without breaking
things.

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

Re: Help! Subversion Exception!

Les Mikesell wrote on Thu, Oct 20, 2011 at 14:31:21 -0500:
> On Thu, Oct 20, 2011 at 2:18 PM, Dave Huang  wrote:
> >
> > On Oct 20, 2011, at 2:03 PM, Les Mikesell wrote:
> >> No, I'm just being difficult because you didn't seem to care about the
> >> potential for losing uncommitted changes.
> >
> > Why would you lose them? The upgrade process doesn't delete or
> > modify your files, right? It only changes the contents of the .svn
> > dir.
> >
> > As has been posted (I don't remember which thread; probably not this
> > one, but in one of the numerous threads about this issue), you can
> > just use some sort of diff utility to copy your uncommitted changes
> > to a clean checkout. If you don't have any uncommitted deletes, you
> > could even just delete all .svn dirs in your broken WC, then copy
> > what's left on top of the fresh WC. Something to the effect of:
> >
> > cd $broken_wc; find . -name .svn | xargs rm -r; pax -rw . $fresh_wc
> >
> > (untested, but you get the idea)
> 
> I'd sort of expect an rsync with the -C option to get it mostly right.
>  But then again I would have expected a 1.6 working copy that was
> working with 1.6 programs

For the checksum issue, 1.6 would also have complained the next time it
touched the victim file.  That's probably true for some of the other
reported issues too.

Re: Help! Subversion Exception!

2011-10-20 Thread Andreas Krey

On Thu, 20 Oct 2011 21:27:38 +, Daniel Shahaf wrote:
> Andreas Krey wrote on Thu, Oct 20, 2011 at 20:38:58 +0200:
> > On Thu, 20 Oct 2011 19:26:06 +, Daniel Shahaf wrote:
> > > Have users always run 'svn cleanup' before they leave for the night on
> > > 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.
> > 
> 
> Ahem, that's exactly how has been working, since years.

Then obviously (and already agreed on elsewhere) svn cleanup is not
sufficient to avoid the checksum problem, and the advice of running
clean up after a ^C doesn't really help.

Which I have the slight impression could be caused by user grepping
for something and then editing the pristine copy by mistake.

Andreas

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

Re: Help! Subversion Exception!

Andreas Krey wrote on Thu, Oct 20, 2011 at 22:07:42 +0200:
> Which I have the slight impression could be caused by user grepping
> for something and then editing the pristine copy by mistake.

The text-base files have the "read only" permission set.  If people edit
them they should consider themselves on the wrong side of the "Don't do
that" fence.

Re: mergeinfo marked not inheritable on sparse checkout

2011-10-20 Thread Douglas Wilson



On Oct 20, 10:45 am, Stefan Sperling  wrote:
>
> Which version of SVN are you running when you hit the problem
> you described in your first post? 1.6 or 1.7?

Subversion 1.7.0

Re: Vedr: revision number offset

2011-10-20 Thread Ryan Schmidt

On Thu, Oct 20, 2011 at 10:08, morten bjoernsvik wrote:

> In many cases with small projects I move the repository around
> (like we have been used to with git)
> svnadmin dump  | bzip2 > repository_revXX.svndump.bz2
> and then:
> svnadmin create 
> bzip2 -dc repository_revXX.svndump.bz2 | svnadmin load 
> This works fine up to around 100-150 revisions, then it becomes slow [...]

In what way does it become slow?

Many projects have much larger repositories that are not slow. The MacPorts 
Project's repository has over 86,000 revisions now; the Apache Foundation's 
Subversion repository has over a million revisions.

On Oct 20, 2011, at 10:14, morten bjoernsvik wrote:

> I also like to clean up repositores from time to time, aka
> a svnadmin -rXX:YY dump then delete and load to only save the latest 10 
> revisions and drop the rest.

Subversion really isn't designed to be used in this manner. svnadmin is meant 
to be used for infrequent administrative tasks, not as a part of a user's 
regular interaction with a repository. And Subversion is designed to keep your 
history; it's more or less deliberately difficult to eradicate history. If you 
really want to do that, you can, but maybe a different version control system 
would fit your way of working better.

FYI

2011-10-20 Thread Eric Gervais

After reverting changes to the a file I got the below exception.

 

I recently upgraded my client to 1.7 (from 1.6) and converted all my
working copies.

 

 

 

---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

(users@subversion.apache.org)

with as much information as possible about what

you were trying to do.

But please first search the mailing list archives for the error message

to avoid reporting the same problem repeatedly.

You can find the mailing list archives at

http://subversion.apache.org/mailing-lists.html

 

Subversion reported the following

(you can copy the content of this dialog

to the clipboard using Ctrl-C):

 

In file

'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion
\libsvn_wc\workqueue.c'

line 672: assertion failed (checksum != NULL)

---

OK   

---

 

Eric Gervais | Senior Software Developer

 

 

   egerv...@immersion.com  |
514.987.9800 x5126 | 4200 St. Laurent Boulevard, Ste. 1105 | Montreal QC
H2W 2R2 Canada

 

This email contains Immersion confidential and proprietary information
intended solely for the addressee, is subject to confidentiality
obligations, and may contain information that is private, privileged,
confidential or exempt from disclosure under applicable law. This email
and the information it contains must not be forwarded or otherwise
disclosed to any third party without permission.

 

If you are not the intended recipient or it appears that this mail has
been forwarded to you without proper authority, you are notified that
any disclosure, copying, distribution or use of the contents of this
email is strictly prohibited.  If you receive this email in error,
please delete this email from your records and notify us immediately.

 

<>

Error attempting to commit changes.

2011-10-20 Thread James Moore

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
with as much information as possible about what you were trying to do.
But please first search the mailing list archives for the error message to
avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog to the clipboard using Ctrl-C):

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 9465: assertion failed (work_presence == svn_wc__db_status_normal ||
work_presence == svn_wc__db_status_not_present || work_presence ==
svn_wc__db_status_base_deleted)

As much information as possible:
On Monday, 17-Oct-2011, I upgraded to 1.7.0 (64bit) on my client machine. Our
server is still on 1.5.?? It asked me to clean/upgrade my local database and I
did. I can update and updates are received without incident. I have even
committed code since Monday, once or twice. I have had no conflicts. I DID
have files pending when I upgraded to 1.7.0. Those files are still pending
(we're going to make a branch before I can commit those). However, I have
modified other files and am now attempting to commit them when I get this error
as the program is attempting to build the file list to show which files have
been modified.

What I've done: I've rebooted my machine - result: no change.
Let me know what I can do to help find a solution to this. Thanks!

-James

RE: Merge strategies?

2011-10-20 Thread Bob Archer

> On 20.10.2011 17:55, Bob Archer wrote:
> >> On 19.10.2011 14:00, Stefan Sperling wrote:
> >>> On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote:
>  What about my other fears, bloated svn:mergeinfo
> >>>
> >>> The entire svn:mergeinfo property is stored in RAM and parsed from
> >>> string form into a data structure (nested hash table) before it is used.
> >>> With modern hardware, you'd have to hit svn:mergeinfo sizes that go
> >>> into hundreds of megabytes before you'll notice any slowdown.
> >>>
> >>
> >> Hm, but this parsing occurs on every invocation of "svn.exe", or I'm
> >> missing something?
> >>
>  and svn:mergeinfo conflicts?
> >>>
> >>> Have you ever seen a mergeinfo conflict? I haven't.
> >>>
> >>
> >> I haven't, too, because everyone uses --ignore-ancestry here ;-)
> >
> > We've moved away from using trunk to simplify our merging and eliminate
> cyclic merges.
> >
> > We have something like:
> >
> > Project
> > /Version1
> > /Version2
> > /Branches
> >/Feature1
> >/Feature2
> > /Tags
> >/Release1
> >/Release2
> >
> > We release from the VersionX path. When we start on a new release a new
> VersionX path is created by copying (branching) from the previous version.
> Feature branches are created from a VersionX path then reintegrated when
> the features is complete. We only use feature branches for stuff that will
> take more than on sprint.
> >
> > The above has really helped the organization of our build server since we
> don't have to constantly wonder what version is in progress on trunk.
> >
> > If we fix an issue in a specific version those changes are merged up into
> each version as needed. We generally don't deal with more than 3 versions
> at a time so the "up merging" is rarely need beyond 2 merges.
> >
> > It's not perfect but it works much better for us than stable trunk, branch 
> > for
> release was working. And all the devs easily understand what it is what path
> when they browse the repo.
> >
> > BOb
> 
> Thank you for your answer. A couple of questions:
> 
> 1) Do you usually merge upstream or downstream?
> 2) Do you set mergeinfo when merging downstream?
> 3) Do you set mergeinfo when merging upstream?
> 4) Do you set mergeinfo when merging from feature branch?
> 

1) We generally only merge up version. A fix is made in the earliest version 
path where we are going to release it and then merged up to the newer versions. 
There may be a case where we made a change in a version and needed it in the 
old version. I'm not sure that happened yet. I assume if it is ever don I would 
do a record-only merge of the rev in the next version's path so it won't 
conflict in future merges.

2, 3 and 4) We always use mergeinfo. (svn sets it automatically)

BOb

Re: Error attempting to commit changes.