Re: Maxsize of Properties

[Bettual Richter]

Von:
Ryan Schmidt 
An:
Bettual Richter 
Kopie:
users@subversion.apache.org
Datum:
21.05.2010 16:36
Betreff:
Re: Maxsize of Properties



On May 21, 2010, at 06:39, Bettual Richter wrote:

>>> Ryan Schmidt wrote:
>> 
>>> On May 20, 2010, at 05:40, Bettual Richter wrote:
>>> 
 does  anyone know if there is some kind of maxsize for revision 
properties ? 
>>> 
>>> I'm not sure.
>>> 
 I'd like to set long revision properties on a repository. 
>>> 
>>> How large? 
>> 
>> I'm not really sure how large the properties are finally going to be 
>> but lets say like 10 000 000 charaters would be quite desirable.

>Based on the error message "413 Request Entity Too Large", I'm guessing 
that's too large.

>When you're serving your repository via Apache, Subversion properties are 
implemented as WebDAV properties, I think. I found a reference [1] that 
says the WebDAV spec doesn't limit the size >of properties, but that some 
implementations might. I guess maybe Apache and/or Subversion do impose a 
limit of some kind.

>Properties are designed for short strings, like the name of the author, 
the date and time, the log message. It therefore wouldn't surprise me to 
find out that this infrastructure is not >prepared to accept a property 
with 10MB of data.

>If I'm right about Subversion properties being implemented as WebDAV 
properties, then you might have success bypassing WebDAV, i.e. using 
svnserve. Or that might fail too. I haven't tried.


>[1] 
>http://books.google.com/books?id=LN6PRtgiwNgC&pg=PA164&lpg=PA164&dq=maximum+size+of+webdav+property&source=bl&ots=RzC0RsrP0A&sig=FeEp0d-X62pSLfvpfQf3He2yX3k&hl=en&ei=9nL2S6KFBIOUMdCPkIQI&sa=X&oi=book_result&ct=result&resnum=10&ved=0CDkQ6AEwCQ


Thanks, at the moment my hint is also the Apache which limits the bodysize 
of a http request. 
Hopefully that's a way to solve this issue but I still have to test it 
first.

We wish to use the Information in properties to make sure every client 
used 
on our repositories is able to read them.

RE: Reintegrate a branch issue

[Erik Hemdal]

1)  When I attempt to reintegrate, I am getting the following error: Error: 
Retrieval of mergeinfo unsupported by '...my repo path...'.  The research that 
I've done suggested I need to upgrade my server version of Subversion, but I 
would like to avoid doing this because of the corporate red tape.  Any other 
suggestions?


What client and version are you using?  Recent versions of TSVN, for example, 
support an easy Reintegrate option, but the server-side has to be at a version 
to support it.  This sounds like a version mismatch related to automatic merge 
tracking, and that you have a more-recent client and a not-so-recent server.

If that's the case, you could try the old-fashioned way of merging ranges of 
revisions and track merges by hand.  Automatic merge tracking isn't going to 
work unless the server knows about it.

Erik

Re: Maxsize of Properties

[Erik Huelsmann]

Dear Bettual,

Making sure all clients can read them isn't a purpose by itself. I hope you
don't have too many files with 10MB properties, or that you have huge
amounts of memory in your clients: they are designed for small amounts of
data and may be read fully into memory for many files at the same time.

Hope that explains Hyrum's question.

Bye,


Erik.
On Tue, May 25, 2010 at 10:47 AM, Bettual Richter <
bettual.richter_ext...@ppi.de> wrote:

>
>
>   Von:
> Ryan Schmidt 
>  An:
> Bettual Richter 
>  Kopie: users@subversion.apache.org Datum: 21.05.2010 16:36 Betreff: Re:
> Maxsize of Properties
> --
>
>
>
> On May 21, 2010, at 06:39, Bettual Richter wrote:
>
> >>> Ryan Schmidt wrote:
> >>
> >>> On May 20, 2010, at 05:40, Bettual Richter wrote:
> >>>
>  does  anyone know if there is some kind of maxsize for revision
> properties ?
> >>>
> >>> I'm not sure.
> >>>
>  I'd like to set long revision properties on a repository.
> >>>
> >>> How large?
> >>
> >> I'm not really sure how large the properties are finally going to be
> >> but lets say like 10 000 000 charaters would be quite desirable.
>
> >Based on the error message "413 Request Entity Too Large", I'm guessing
> that's too large.
>
> >When you're serving your repository via Apache, Subversion properties are
> implemented as WebDAV properties, I think. I found a reference [1] that says
> the WebDAV spec doesn't limit the size >of properties, but that some
> implementations might. I guess maybe Apache and/or Subversion do impose a
> limit of some kind.
>
> >Properties are designed for short strings, like the name of the author,
> the date and time, the log message. It therefore wouldn't surprise me to
> find out that this infrastructure is not >prepared to accept a property with
> 10MB of data.
>
> >If I'm right about Subversion properties being implemented as WebDAV
> properties, then you might have success bypassing WebDAV, i.e. using
> svnserve. Or that might fail too. I haven't tried.
>
>
> >[1]
> >http://books.google.com/books?id=LN6PRtgiwNgC&pg=PA164&lpg=PA164&dq=maximum+size+of+webdav+property&source=bl&ots=RzC0RsrP0A&sig=FeEp0d-X62pSLfvpfQf3He2yX3k&hl=en&ei=9nL2S6KFBIOUMdCPkIQI&sa=X&oi=book_result&ct=result&resnum=10&ved=0CDkQ6AEwCQ
>
>
> Thanks, at the moment my hint is also the Apache which limits the bodysize
> of a http request.
> Hopefully that's a way to solve this issue but I still have to test it
> first.
>
> We wish to use the Information in properties to make sure every client used
>
> on our repositories is able to read them.
>
>
>

RE: Using * in AuthzSVNAccessFile file

[Andrea Antonio Maleci]

You can use svnperms.py on pre-commit hook, which allows regular expressions.
You can’t use groups from your svn_access_file: you have to redefine your 
allowed users and groups on svnperms.conf file.

Hope this helps,
Andrea


From: Sarah George [mailto:sarah.geo...@gmail.com]
Sent: martedì 25 maggio 2010 4.14
To: Johan Corveleyn
Cc: vishwajeet singh; Prakash Velayutham; users@subversion.apache.org
Subject: Re: Using * in AuthzSVNAccessFile file


You can’t put in arbitrary wildcards, but you don’t have to specify a 
repository.

If you use one project per repository (which I highly recommend), then you can 
just define

[/trunk/passwords]
*=

or similar to set up permissions for the same path in all projects.

— Sarah
Codesion.com



On 21 May 2010 18:05, Johan Corveleyn 
mailto:jcor...@gmail.com>> wrote:
On Thu, May 20, 2010 at 10:48 PM, vishwajeet singh 
mailto:dextrou...@gmail.com>> wrote:
>
>
> On Fri, May 21, 2010 at 2:16 AM, Prakash Velayutham
> mailto:prakash.velayut...@cchmc.org>> wrote:
>>
>> Hi,
>>
>> Is it possible to use '*' in the path portion of a AuthzSVNAccessFile.
>>
>> Like
>>
>> [repo:/folder1/*/*/bc]
>> @group1 = rw
>> @group2 = r
>> @admin = rw
>>
>> Would this work? In the redbook, it only talks about using '*' for the
>> user/group portion, not the path.
>
>
>Not it would not work.
FYI, there is an (open) enhancement request for this:
http://subversion.tigris.org/issues/show_bug.cgi?id=2662 - authz with wildcards

It seems that several patches were created for this, but for some
reason they were never committed. Maybe someone with interest in this
issue should try to take a look at those patches again, bring them up
on the dev list for review, ...

Cheers,
--
Johan

Why am I getting a bad merge?

[Steven Boswell II]

I recently began using Subversion to track a project at the new company where I 
work.  We've been using it for a few weeks, and our database has just over 60 
commits to it now.

I created a "release" branch of the project at revision 36, and have been doing 
heavy development in the trunk, merging only the bug fixes into the branch.  It 
now looks like my trunk changes are fine, and I wanted to merge them into the 
release branch, but that's where things went wrong.  Most of the files were 
fine, but one file missed a very large change!

In the branch, that file had a change at revision 62, and as mentioned above, 
the branch was created in revision 36.  In the trunk, that file was modified in 
revisions 61, 59, 37, 23, and points earlier.  The single merge of that file 
into the branch was done with "svn merge -r61:62 ", run on the parent 
directory.  When I try to merge the trunk version of that file into the branch, 
I get:

--- Merging r47 through r62 into '':
U  

As you can see, it skips the change to the file made in revision 37!  
Specifying "-r36:62" in the command line gives the same result.  I'm not even 
sure why it's mentioning revision 47, because the file wasn't changed then.

"svn propget svn:mergeinfo --depth infinity " shows nothing, not 
even the merge from "-r61:62".

In addition, I can't seem to produce an accurate dump to show others for 
debugging purposes -- I try "svnadmin dump  | svndumpfilter 
--drop-empty-revs include   > repodump.txt", but the 
only revision shown for the branch path is 62...there's no mention of the 
creation of the branch back in revision 36, so reconstructing the database 
fails -- the branch path never gets created.  (And yes, I created all the 
parent directories directly...I dug around the mailing-list archives and found 
out that step was necessary for filtered dumps.)

There's another problem, which is that some files I deleted in the trunk showed 
up in the merged branch as conflicts, but that's a separate problem, and at 
least that problem drew attention to itself -- the bad merge I described above 
had to be found by reading over all the changes one by one.

Does anyone have any idea what could have gone wrong?  This seems like an 
out-and-out bug in Subversion.

I'm running CollabNetSubversion-server-1.6.11-3.win32 on a machine running 
Windows Server 2008, and CollabNetSubversion-client-1.6.11-3.win32 and 
TortoiseSVN-1.6.8.19260-win32-svn-1.6.11 on a laptop running Windows Vista.  
Most of my commits were done with TortoiseSVN, but all my merges were done with 
the command-line client.

Thanks in advance for any insight into these problems!  I'm trying to sell the 
concept of version control (and open-source software) to a team with some 
rather backwards development processes, and this glitch isn't helping my case.

Steven Boswell




  

Re: How to speed up subversion

[David Brodbeck]

On May 24, 2010, at 2:05 PM, Les Mikesell wrote:

> On 5/24/2010 3:51 PM, David Brodbeck wrote:
>> 
>> On May 21, 2010, at 8:23 AM, Hyrum K. Wright wrote:
>>> Actually, Subversion is a bit more intelligent about it, attempting to use 
>>> modification times and sizes, before doing a byte-by-byte comparison.
>> 
>> Even that can be slow if there are lots of files involved.  Note that some 
>> filesystems have particularly bad performance if there are lots of files in 
>> a single directory, as well.  This is especially true of NFS.  In one 
>> extreme example, I've seen a simple "ls" take tens of minutes to produce any 
>> output in an NFS-mounted directory with ~1,000,000 files.
> 
> But to be fair, note that ls sorts its output, so it can't output anything 
> until it has read everything.

True, but other operations were slow, too.  The way readdir() works means that 
a lot of file operations inevitably involve a linear search of the directory.

-- 

David Brodbeck
System Administrator, Linguistics
University of Washington

Re: How to speed up subversion

[Les Mikesell]

On 5/25/2010 11:44 AM, David Brodbeck wrote:


On May 24, 2010, at 2:05 PM, Les Mikesell wrote:


On 5/24/2010 3:51 PM, David Brodbeck wrote:


On May 21, 2010, at 8:23 AM, Hyrum K. Wright wrote:

Actually, Subversion is a bit more intelligent about it, attempting to use 
modification times and sizes, before doing a byte-by-byte comparison.


Even that can be slow if there are lots of files involved.  Note that some filesystems 
have particularly bad performance if there are lots of files in a single directory, as 
well.  This is especially true of NFS.  In one extreme example, I've seen a simple 
"ls" take tens of minutes to produce any output in an NFS-mounted directory 
with ~1,000,000 files.


But to be fair, note that ls sorts its output, so it can't output anything 
until it has read everything.


True, but other operations were slow, too.  The way readdir() works means that 
a lot of file operations inevitably involve a linear search of the directory.


And worse, creating a new file involves doing that search first to see 
if it is new, then finding a free slot or growing the directory and 
adding it all as an atomic operation, blocking any other process trying 
to do the same. But, that's why subdirectories were invented - you don't 
have to put everything on one big inefficient space.


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

Re: How to speed up subversion

[David Brodbeck]

On May 25, 2010, at 9:59 AM, Les Mikesell wrote:

> On 5/25/2010 11:44 AM, David Brodbeck wrote:
>> 
>> On May 24, 2010, at 2:05 PM, Les Mikesell wrote:
>> 
>>> On 5/24/2010 3:51 PM, David Brodbeck wrote:
 
 On May 21, 2010, at 8:23 AM, Hyrum K. Wright wrote:
> Actually, Subversion is a bit more intelligent about it, attempting to 
> use modification times and sizes, before doing a byte-by-byte comparison.
 
 Even that can be slow if there are lots of files involved.  Note that some 
 filesystems have particularly bad performance if there are lots of files 
 in a single directory, as well.  This is especially true of NFS.  In one 
 extreme example, I've seen a simple "ls" take tens of minutes to produce 
 any output in an NFS-mounted directory with ~1,000,000 files.
>>> 
>>> But to be fair, note that ls sorts its output, so it can't output anything 
>>> until it has read everything.
>> 
>> True, but other operations were slow, too.  The way readdir() works means 
>> that a lot of file operations inevitably involve a linear search of the 
>> directory.
> 
> And worse, creating a new file involves doing that search first to see if it 
> is new, then finding a free slot or growing the directory and adding it all 
> as an atomic operation, blocking any other process trying to do the same. 
> But, that's why subdirectories were invented - you don't have to put 
> everything on one big inefficient space.

Yup.  Now I just need to convince my users of that. ;)

-- 

David Brodbeck
System Administrator, Linguistics
University of Washington

RE: svn support for symbolic link?

[Todd Gleason]

> -Original Message-
> From: Andy Levy [mailto:andy.l...@gmail.com]
> Sent: Monday, May 24, 2010 2:23 PM
> To: Lars Tiefland
> Cc: Brown, Michael; Peng Yu; users@subversion.apache.org
> Subject: Re: svn support for symbolic link?
>
> On Mon, May 24, 2010 at 16:10, Lars Tiefland 
> wrote:
> > But: Only a Linux / Unix client will preserve symbolic links. On
> Windows the
> > link will become a normal file.
>
> Actually, it'll be a file that basically contains "you should be
> looking at another file, look over there". The link isn't "resolved"
> to the file it points to.

I believe Windows 2000 and up (NTFS 5.0+ really) supports junctions that are 
nearly identical to Unix symbolic links.  See 
http://shell-shocked.org/article.php?id=284 .  At the very least directory 
symbolic links are supported, and file links may be as well.  So is there a 
good reason for svn not to support this in Windows?

--Todd


Please consider the environment before printing this e-mail.

The contents of this e-mail message (including any attachments) are 
confidential to and are intended to be conveyed for the use of the recipient to 
whom it is addressed only. If you receive this transmission in error, please 
notify the sender of this immediately and delete the message from your system.  
Any distribution, reproduction or use of this message by someone other than 
recipient is not authorized and may be unlawful.
***Internet Email Confidentiality Footer***
The contents of this e-mail message (including any attachments hereto) are 
confidential to and are intended to be conveyed for the use of the recipient to 
whom it is addressed only. If you receive this transmission in error, please 
notify the sender of this immediately and delete the message from your system. 
Any distribution, reproduction or use of this message by someone other than 
recipient is not authorized and may be unlawful.

Re: Automatic commission?

[David Weintraub]

On Mon, May 24, 2010 at 6:03 PM, Peng Yu  wrote:
> I might change filenames or even move files around several times
> before I 'commit'. Since I need tell svn the renames and moves that I
> have done, does svn keep all the intermediate changes when I finally
> 'commit'.
>
> I think that svn should not keep track of the intermediate changes
> after 'commit'. But I'm not sure if svn is doing so. Could you please
> let me know if it is the case?

Do you know that most version control systems don't track renaming and
moving at all? Subversion is one of the few that does it. In fact, I
don't know of any version control system that can track random file
renaming with the operating system rename/move commands.

Normally, once you name a file or place a file in a particular
directory, you don't change it because it causes confusion. In many
version control systems, the renamed or moved file is not the same as
the old one, and in the version control systems that support renaming,
moving or renaming files causes user confusion. You simply don't do it
unless you have to.

However, to answer your question, as long as you use Subversion's move
command, Subversion will track everything until you get the final name
you want:

$ ls
bar  foo

$ svn mv foo barfoo
D   foo
C   barfoo

$ls
barbarfoo

$ svn mv barfoo foobar
D  barfoo
C  foobar

$svn status
D  foo
C  barfoo

As others have suggested, why not download Subversion? It's free and
there are no licenses. Follow the examples in the book at
http://svnbook.com. See if it does what you want.

That will answer most of your questions on how Subversion works. You
can find the right binary on:
.

-- 
David Weintraub
qazw...@gmail.com

Re: svn support for symbolic link?

[Andy Levy]

On Tue, May 25, 2010 at 14:20, Todd Gleason  wrote:
>> -Original Message-
>> From: Andy Levy [mailto:andy.l...@gmail.com]
>> Sent: Monday, May 24, 2010 2:23 PM
>> To: Lars Tiefland
>> Cc: Brown, Michael; Peng Yu; users@subversion.apache.org
>> Subject: Re: svn support for symbolic link?
>>
>> On Mon, May 24, 2010 at 16:10, Lars Tiefland 
>> wrote:
>> > But: Only a Linux / Unix client will preserve symbolic links. On
>> Windows the
>> > link will become a normal file.
>>
>> Actually, it'll be a file that basically contains "you should be
>> looking at another file, look over there". The link isn't "resolved"
>> to the file it points to.
>
> I believe Windows 2000 and up (NTFS 5.0+ really) supports junctions that are 
> nearly identical to Unix symbolic links.  See 
> http://shell-shocked.org/article.php?id=284 .  At the very least directory 
> symbolic links are supported, and file links may be as well.  So is there a 
> good reason for svn not to support this in Windows?
>

True symlink support in NTFS (at the level that's required here)
didn't come until Vista. IIRC, junctions aren't as identical to *NIX
symlinks as they seem.

Does Vista/Win7 have a good way of creating/managing symlinks, or is
it one of those command-line programs you only know about if you go
looking for it?

In Subversion, it's actually APR which would have to support symlinks
I believe, and then you'd have to do some FS "sniffing" to check
whether you are working on a disk which really does support it.

Re: svn support for symbolic link?

[David Weintraub]

On Mon, May 24, 2010 at 3:25 PM, Peng Yu  wrote:
> For some reason, I need to create symbolic link in my source
> directory. When the directory structure is changed, I have some tools
> to fix broken links.
>
> I'm wondering if svn support symbolic links.

I know that the Unix version of Subversion supports symbolic links,
but I don't know if the Windows version does on Vista and Windows 7. I
can tell you it doesn't on earlier versions of Windows.

Yes, I know that NTFS supports something like symbolic links and that
since Vista, actual symbolic links are supported in NTFS via the
mklink command. However, since by default non-administrative users
ren't allowed to create symbolic links and junctions, most Windows
programs like Subversion don't support them either. Besides, there's
no guarantee you're using NTFS and not FAT32 on your Windows
partition.

It is normally not a good idea to use symbolic links in a version
control even in cases where it is fully supported. You're usually
better off having a utility create the symbolic links for you at build
or installation time. As you stated, when you have symbolic links,
they tend to break when things like directory structures change.

In fact, the truth is that Subversion doesn't really handle symbolic
links at all. They're just stored in the repository as a regular file
with a "svn:special" property attached to them. It is up to the
Subversion client to figure out that they're really symbolic links and
to create the symbolic link. The Subversion Unix command line client
does this. I don't know about the Windows Subversion client on Windows
Vista and Windows 7, and since I don't have a copy of those operating
systems, I can't even try it.

If you have a Windows 7 machine, you can create a local repository,
checkout to a local working directory. Create a symbolic link, add it
to the repository and commit the change. Check out the project
somewhere else and see what happens.

-- 
David Weintraub
qazw...@gmail.com

RE: svn support for symbolic link?

[Keith Moore]

-Original Message-
From: David Weintraub [mailto:qazw...@gmail.com] 
Sent: Wednesday, 26 May 2010 5:05
To: Peng Yu
Cc: users@subversion.apache.org
Subject: Re: svn support for symbolic link?

On Mon, May 24, 2010 at 3:25 PM, Peng Yu  wrote:
> For some reason, I need to create symbolic link in my source
> directory. When the directory structure is changed, I have some tools
> to fix broken links.
>
> I'm wondering if svn support symbolic links.

I know that the Unix version of Subversion supports symbolic links,
but I don't know if the Windows version does on Vista and Windows 7. I
can tell you it doesn't on earlier versions of Windows.

Yes, I know that NTFS supports something like symbolic links and that
since Vista, actual symbolic links are supported in NTFS via the
mklink command. However, since by default non-administrative users
ren't allowed to create symbolic links and junctions, most Windows
programs like Subversion don't support them either. Besides, there's
no guarantee you're using NTFS and not FAT32 on your Windows
partition.

It is normally not a good idea to use symbolic links in a version
control even in cases where it is fully supported. You're usually
better off having a utility create the symbolic links for you at build
or installation time. As you stated, when you have symbolic links,
they tend to break when things like directory structures change.

In fact, the truth is that Subversion doesn't really handle symbolic
links at all. They're just stored in the repository as a regular file
with a "svn:special" property attached to them. It is up to the
Subversion client to figure out that they're really symbolic links and
to create the symbolic link. The Subversion Unix command line client
does this. I don't know about the Windows Subversion client on Windows
Vista and Windows 7, and since I don't have a copy of those operating
systems, I can't even try it.

If you have a Windows 7 machine, you can create a local repository,
checkout to a local working directory. Create a symbolic link, add it
to the repository and commit the change. Check out the project
somewhere else and see what happens.

-- 
David Weintraub
qazw...@gmail.com

I tried this on Windows 7 Enterprise with TortoiseSVN 1.6.8, Subversion 1.6.11 
and got the error message "svn: Symbolic links are not supported on this 
platform".  Now, I know these error messages can be a bit cryptic so I googled 
this one and it actually means that symbolic links are not supported on Window 
7 ;o)

#
Attention:
The information contained in this message and or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender and
delete the material from any system and destroy any copies.
#

RE: svn support for symbolic link?

[Keith Moore]

-Original Message-
From: David Weintraub [mailto:qazw...@gmail.com] 
Sent: Wednesday, 26 May 2010 5:05
To: Peng Yu
Cc: users@subversion.apache.org
Subject: Re: svn support for symbolic link?

On Mon, May 24, 2010 at 3:25 PM, Peng Yu  wrote:
> For some reason, I need to create symbolic link in my source
> directory. When the directory structure is changed, I have some tools
> to fix broken links.
>
> I'm wondering if svn support symbolic links.

I know that the Unix version of Subversion supports symbolic links,
but I don't know if the Windows version does on Vista and Windows 7. I
can tell you it doesn't on earlier versions of Windows.

Yes, I know that NTFS supports something like symbolic links and that
since Vista, actual symbolic links are supported in NTFS via the
mklink command. However, since by default non-administrative users
ren't allowed to create symbolic links and junctions, most Windows
programs like Subversion don't support them either. Besides, there's
no guarantee you're using NTFS and not FAT32 on your Windows
partition.

It is normally not a good idea to use symbolic links in a version
control even in cases where it is fully supported. You're usually
better off having a utility create the symbolic links for you at build
or installation time. As you stated, when you have symbolic links,
they tend to break when things like directory structures change.

In fact, the truth is that Subversion doesn't really handle symbolic
links at all. They're just stored in the repository as a regular file
with a "svn:special" property attached to them. It is up to the
Subversion client to figure out that they're really symbolic links and
to create the symbolic link. The Subversion Unix command line client
does this. I don't know about the Windows Subversion client on Windows
Vista and Windows 7, and since I don't have a copy of those operating
systems, I can't even try it.

If you have a Windows 7 machine, you can create a local repository,
checkout to a local working directory. Create a symbolic link, add it
to the repository and commit the change. Check out the project
somewhere else and see what happens.

-- 
David Weintraub
qazw...@gmail.com



Sorry, forgot to mention that I got the error when trying to commit.
#
Attention:
The information contained in this message and or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender and
delete the material from any system and destroy any copies.
#

truMerge 1.1.0 released

[Schellingerhout, Nico]

Dear Subversion users,



I am happy to announce the release of truMerge 1.1.0.



truMerge is a merge helper tool that combines true 
rename 
functionality with Subversion merge, in order to handle tree conflicts more 
reliably and effectively. truMerge not only recognizes but also handles most 
tree conflicts automatically.



This release sports the following features:

* Supports normal, reverse, and reintegration merges

* Automatic resolution of a wide range of tree conflicts

* Supports multiple OS platforms (tested on Windows XP, Ubuntu 10.04)

* Supports merge tracking (compatible with native svn merge tracking in 1.5 
and higher)

* Compatible with svn 1.5 and 1.6

* Supports merging into working copies that have local modifications

* Supports merging multiple revision ranges as well as automatically 
skipping already merged revisions



You can grab the release here:



http://trumerge.open.collab.net/files/documents/211/3472/truMerge-1.1.0.zip



For more information, please visit the truMerge project on open.collab.net: 
http://trumerge.open.collab.net/



Best regards,



Nico

--

N.W. Schellingerhout

Philips Healthcare



The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.