Planning to move to 1.1rc2 this weekend (possibly)

[David Budworth <db...@eloan.com>]

Just wanted to get an idea of the general publics feelings on 1.1rc2's 
data retention.

I noticed that a corruption bug was fixed from rc1 -> rc2 and I'm just 
trying to figure out if anyone has put a production server on the new 
stuff.

We would be moving about 3.1GB of bdb repository over to fsfs with the 
plan of converting our larger CVS tree (cvs2svn ends up with a 3.7GB 
29k commit dumpfile) shortly there after.

The switch to fsfs is mainly for my own peace of mind and false sense 
of security for the PHBs who lurk on the list and see all the BDB 
issues people have.

Ultimately, I know there are no guarantees but I'm just hoping that if 
we do run in to something, repairing a fsfs broken repo would be 
possible.

I'd guess that fixing the broken repo may be as easy as deleting the 
offending commit files+ (meaning deleting commit 670->current would put 
us back to 669)  but that's just a guess as I've never actually seen a 
fsfs filesystem on disk.

Main reason for this switch is I believe that 1.1 has better support 
for mass merging than 1.0 did given that merge now follows history?  Or 
maybe I just misread something about that.
As it stands now, every few days I spend several hours merging peoples 
branches to the trunk , mostly conflict resolution.  It's mainly just 
me as I'm the code reviewer here and part of that review is to merge to 
trunk and run testsuites.

Thank you for your time,
-David Budworth



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Planning to move to 1.1rc2 this weekend (possibly)

[David Budworth <db...@eloan.com>]

On Aug 12, 2004, at 3:39 PM, Ben Collins-Sussman wrote:

> On Thu, 2004-08-12 at 17:34, David Budworth wrote:
>
>> Main reason for this switch is I believe that 1.1 has better support
>> for mass merging than 1.0 did given that merge now follows history?  
>> Or
>> maybe I just misread something about that.
>
> You're the 2nd person to misunderstand the new feature.  Maybe we 
> should
> change the release notes...
>
> We don't have merge-tracking.  All the new feature means is that if you
> run
>
>    'svn subcommand -rOLD foo.c'
>
> and foo.c had a different name or location in rOLD, then the svn client
> will "find" that old name and use it, rather than spewing an error 
> about
> how 'foo.c doesn't exist in rOLD'.
>
> A lot of people have been burned by this in svn 1.0, when running 'svn
> diff -rX:Y foo.c', for example, when foo.c was renamed at some point.
>

My mistake then, thank you for the clarification.

Even though it didn't do what I thought, it will still be a big benefit 
as that's a common problem given the amount of re-factoring I do in our 
tree (much to the annoyance of my co-workers).

Just reread them, the release notes where clear enough, it was just a 
case of PEBKAC here.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Planning to move to 1.1rc2 this weekend (possibly)

[Ben Collins-Sussman <su...@collab.net>]

On Thu, 2004-08-12 at 17:34, David Budworth wrote:

> Main reason for this switch is I believe that 1.1 has better support 
> for mass merging than 1.0 did given that merge now follows history?  Or 
> maybe I just misread something about that.

You're the 2nd person to misunderstand the new feature.  Maybe we should
change the release notes...

We don't have merge-tracking.  All the new feature means is that if you
run 

   'svn subcommand -rOLD foo.c'

and foo.c had a different name or location in rOLD, then the svn client
will "find" that old name and use it, rather than spewing an error about
how 'foo.c doesn't exist in rOLD'.

A lot of people have been burned by this in svn 1.0, when running 'svn
diff -rX:Y foo.c', for example, when foo.c was renamed at some point.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org