MergeInfo on individual files - can they be safely removed?

[David Brodie]

Whenever we merge code, many files in our codebase get updated
mergeinfo's with the new revision number, even though they were not
changed in this revision.  From some searching online, this seems to
be a common situation, and it appears it might happen when not doing
merges from the root.  There seems to be two attitudes of people
commenting on this situation: (1) do not remove the mergeinfos as it
might cause problems later on, and (2) it is perfectly fine to remove the
mergeinfos on files so long as the merginfos are preserved on the root
folder, and that merges should always be done  from the root to prevent
mergeinfos from being set on individual files.

Is (2) correct, and it is safe to remove the mergeinfos on individual files?
If it is, I understand that something like the following would work:

|svn propdel svn:mergeinfo -R
svn revert .
svn ci -m "Removed mergeinfo"|


--
David Brodie
BEAMS Release Manager

*CARIS* 
115 Waggoners Lane
Fredericton, New Brunswick
CanadaE3B 2L4
Tel: +1.506.458.8533 Fax: +1.506.459.3849
www.caris.com 

*Connect with CARIS*
Twitter  | LinkedIn 
 | Facebook 
 
| YouTube 


Download your free copy of CARIS Easy View today!
www.caris.com/easyview 

_
This email and any files transmitted with it are confidential and 
intended only for the addressee(s). If you are not the intended 
recipient(s) please notify us by email reply. You should not use, 
disclose, distribute or copy this communication if received in error.


Any views or opinions expressed in this email are solely those of the 
author and do not necessarily represent those of the company. No binding 
contract will result from this email until such time as a written 
document is signed on behalf of the company.

svn up "dry-run"

[Alex Bligh]

I have a working copy with directories d1..dX in, and a repository to which
directories occasionally get added, say d1..dY where Y>X (though the
directory names are not numerical).


From the working copy, is there any way of telling what directories are

missing on that working copy? I don't want to do an "svn up", because I
don't want to lose the current state of d1..dX. I can't do "svn up dY"
because I don't (yet) know the name(s) of the missing directory/directories
dY.

What would be perfect is "svn up --dry-run", producing identical output
to svn up, but not actually doing anything. I could then parse the output
of that. However, that command doesn't' actually exist.

I suppose I could parse the output of "svn diff -r HEAD" but that
seems pretty expensive given it's diffing millions of files and
I only really want the current directory (not subdirectories).

Any ideas?

--
Alex Bligh

AW: MergeInfo on individual files - can they be safely removed?

[André Hänsel]

David Brodie wrote:
> it is perfectly fine to remove the mergeinfos on files
> so long as the merginfos are preserved on the root folder, and that merges
> should always be done  from the root to prevent mergeinfos from being set
> on individual files.

Yes, as long as the mergeinfo is identical, removing it is ok. But if it
really is, subversion itself does that automatically in a process called
"mergeinfo elision" when you merge the whole folder.

Re: svn up "dry-run"

[Stephen Butler]

On May 26, 2011, at 14:52 , Alex Bligh wrote:

> I have a working copy with directories d1..dX in, and a repository to which
> directories occasionally get added, say d1..dY where Y>X (though the
> directory names are not numerical).
> 
>> From the working copy, is there any way of telling what directories are
> missing on that working copy? I don't want to do an "svn up", because I
> don't want to lose the current state of d1..dX. I can't do "svn up dY"
> because I don't (yet) know the name(s) of the missing directory/directories
> dY.
> 
> What would be perfect is "svn up --dry-run", producing identical output
> to svn up, but not actually doing anything. I could then parse the output
> of that. However, that command doesn't' actually exist.
> 
> I suppose I could parse the output of "svn diff -r HEAD" but that
> seems pretty expensive given it's diffing millions of files and
> I only really want the current directory (not subdirectories).
> 
> Any ideas?

Have you tried the following?

   svn status --show-updates --depth immediates

It tells you the names of the incoming items that an update would add 
to the current working copy directory (as well as items that would be 
modified).

Steve

--
Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

Re: svn up "dry-run"

[Stefan Sperling]

On Thu, May 26, 2011 at 01:52:56PM +0100, Alex Bligh wrote:
> I have a working copy with directories d1..dX in, and a repository to which
> directories occasionally get added, say d1..dY where Y>X (though the
> directory names are not numerical).
> 
> >From the working copy, is there any way of telling what directories are
> missing on that working copy? I don't want to do an "svn up", because I
> don't want to lose the current state of d1..dX. I can't do "svn up dY"
> because I don't (yet) know the name(s) of the missing directory/directories
> dY.
> 
> What would be perfect is "svn up --dry-run", producing identical output
> to svn up, but not actually doing anything. I could then parse the output
> of that. However, that command doesn't' actually exist.
> 
> I suppose I could parse the output of "svn diff -r HEAD" but that
> seems pretty expensive given it's diffing millions of files and
> I only really want the current directory (not subdirectories).
> 
> Any ideas?

Have you tried svn status -u ?

Re: svn up "dry-run"

[Alex Bligh]

--On 26 May 2011 15:06:45 +0200 Stephen Butler  wrote:


Have you tried the following?

   svn status --show-updates --depth immediates

It tells you the names of the incoming items that an update would add
to the current working copy directory (as well as items that would be
modified).


Fantastic - thanks.

--
Alex Bligh

RE: How to display historic revisions after a delete

[Dave Sailors]

Hi Stefan,

Thanks, this is exactly what we needed. We appreciate your help.

Dave


-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Sun 5/22/2011 8:26 AM
To: Dave Sailors
Cc: users@subversion.apache.org; David Austin
Subject: Re: How to display historic revisions after a delete
 
On Fri, May 20, 2011 at 01:59:43PM -0700, Dave Sailors wrote:
> When we do a svn delete on a file, it still shows up in that revision of
> the directory for a svn list -r  on the directory itself, but you
> can't list that file by revision number directly. You get an error
> message saying the file isn't in the the current revision of the
> repository.
> 
>  
> 
> Example:
> 
>  
> 
> File
> svn://srn-redhat/opt/vob/cp_vob/cp-image/trunk/sw_snmp/sw_agent/access_r
> psm.c
> 
> Was deleted in revision 5148.
> 
>  
> 
> When we do a svn list we get the following error.
> 
>  
> 
> svn ls -r 5145
> svn://srn-redhat/opt/vob/cp_vob/cp-image/trunk/sw_snmp/sw_agent/access_r
> psm.c
> 
> svn: File not found: revision 5148, path
> '/trunk/sw_snmp/sw_agent/access_rpsm.c'
> 
>  
> 
> This is also a problem with the Subversion diff command.
> 
>  
> 
> Is there something else we need to do to be able to see changes between
> historic versions of files that have been deleted from the repository?

Yes, you need to specify a peg revision.
See http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html

Currently, the best way to find the right peg revision is to log a
known parent directory that still exists in HEAD, and search for
the deleted path in the output.




This E-mail message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended 
recipient,
please contact the sender by reply E-mail and destroy all copies of the original
message.

Disabling automatic setting of svn:executable property

[Daniel Schepler]

We have a lot of users using Subversion under Cygwin, which means that
any files they add get marked as executable by default (and almost
always uselessly).  Is there any way to disable the automatic setting of
the svn:executable property on an "svn add"?  The closest thing I see in
the manual is --no-auto-props, but that doesn't seem to have the desired
effect in a quick test.

-- 

Daniel