Re: Is it safe to remove deleted and no longer used branches from the svn:mergeinfo property?

[Thomas Wicklund]

On 5/31/2017 9:18 AM, Alfred von Campe wrote:
After many years of development, we have over 100 entries in the 
svn:mergeinfo property of our trunk.  I am thinking about manually 
editing the property to remove entries for all branches that have been 
deleted or are no longer used (and should be deleted).  I am hoping 
that once I merge trunk into the other active branches, the cleanup of 
that property will also propagate to the other branches.


So my questions are:

  * Is this safe to do?
  * Will the changes to the properly be merged to all other branches
over time as one would expect?


Thanks,
Alfred



I have done this in the past. mergeinfo got so large it was visibly 
hurting performance. There may have also been svn command crashes but 
it's been several years. I just deleted the mergeinfo property, starting 
over.


If you are basically merging from branches back to a development trunk 
the lack of mergeinfo shouldn't hurt. Do watch that the next time you 
merge a branch into the trunk it doesn't merge the whole huge mergeinfo 
back into the branch.


Personally I've never had much use for mergeinfo. Since the development 
model I work with is to create a branch, make changes, then commit the 
branch changes into the trunk, I generally revert any mergeinfo change 
during the merge before committing the change to the trunk since the 
fact something was done in a branch (which won't be reused) isn't useful 
information, each change looks like it was developed and committed onto 
the trunk.


Tom

Re: svn feature addition?

[Ryan Schmidt]

On Jun 1, 2017, at 18:58, Branko Čibej wrote:

>> -Is there an option to inspect each file further line-by-line for 
>> lines  that have changed to either be selected or excluded from the commit?
> 
> "Including or excluding changed lines from a file before commnt" is also
> known as "using a text editor to modify the file". Subverison tracks
> whole files, not individual lines. In fact the repository does not care
> if the file contains text or not.

Now that one of the projects I work on has switched to git and I'm trying 
(unsuccessfully) to learn it, I've started using GitHub Desktop on my Mac, 
which has this feature. I may have modified several lines in a file, but GitHub 
Desktop gives me checkboxes for each line in the diff so that I can select 
which of them I want to commit. It's the one aspect of working with git that I 
prefer over svn so far.

Re: Is it safe to remove deleted and no longer used branches from the svn:mergeinfo property?

[Stefan Hett]

Hi Alfred,

On 6/2/2017 2:48 PM, Mark Phippard wrote:

Actually, this is the newer tool I was thinking of:

http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-mergeinfo-normalizer/

On Fri, Jun 2, 2017 at 8:46 AM, Mark Phippard > wrote:


Have you seen this script?


http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/mergeinfo-sanitizer.py



I believe it does this though I have never tried it.


On Wed, May 31, 2017 at 11:18 AM, Alfred von Campe
mailto:alf...@von-campe.com>> wrote:

After many years of development, we have over 100 entries in
the svn:mergeinfo property of our trunk.  I am thinking about
manually editing the property to remove entries for all
branches that have been deleted or are no longer used (and
should be deleted).  I am hoping that once I merge trunk into
the other active branches, the cleanup of that property will
also propagate to the other branches.

So my questions are:

  * Is this safe to do?
  * Will the changes to the properly be merged to all other
branches over time as one would expect?




jcorvel made me aware of your post here.

I'm regularly using the svn mergeinfo normalizer myself. It should suit 
your requirements quite well, but you'd be aware that it hasn't been 
tested thoroughly by a lot of people, since it's a new tool in the not 
yet released 1.10 development branch.


To get some basic documentation about what the tool does, best start 
with the integrated help (svn-mergeinfo-normalizer help).
In your case all you might actually need is to run 
"svn-mergeinfo-normalizer normalize --remove-obsoletes" followed by 
committing the changes. Carefully verify the changes before committing 
them. As said: The tool hasn't gotten much test coverage by a broader 
audience yet.


There are also other useful commands (--remove-redundant which tries to 
elide unnecessary mergeinfo entries as well as --combine-ranges which 
will combine mergeinfo ranges into shorter representations where possible).


Useful is also its "svn-mergeinfo-normalizer analyze" command, which 
will print out the information about why certain mergeinfos could not be 
elided (possibly providing you with the necessary information to correct 
some invalid/incorrect mergeinfo entries which might have built up over 
time).


As said above: I cannot emphasize enough to be careful with using that 
tool atm. While I've personally been playing around with it for over two 
years now, it might still contain undetected issues/bugs.


If you wanna give it a quick try and are running on Windows, there are 
prebuilt binaries available for MaxSVN (disclaimer: that's a development 
binary distribution of SVN I'm maintaining): 
http://www.luke1410.de/typo3/index.php?id=97. Download MaxSVN 
trunk-dev-r1771118-1 and run svn-mergeinfo-normalizer contained in the 
package. I'm not aware of other prebuilt sources of the current SVN 
development branch (otherwise I'd have listed them here as other examples).


On a more general note on your questions:
Is it safe to do that (i.e. remove the entries for obsolete/removed 
branches)?


Kind of. If your working process means that you are not going to 
reinstate the removed branch in a future revision again to merge 
remaining revision from it to some other branch, I'd personally consider 
it a safe habit to drop the then obsolete mergeinfos. If your work 
process differs, you should not remove it though IMO, since then you 
might cause conflicts on merges and also lose the information about what 
was merged of the other branch (if it later is reinstated).


Will the changes to the properly be merged to all other branches over 
time as one would expect?


That depends on how your merge process goes and how previous merges were 
done. Simply speaking, I'd suggest to remove the obsolete mergeinfos 
from any branch (not only trunk or specific development branches). Not 
doing so can reinstate the removed obsolete mergeinfos again (due to 
following merge operations). Another situation you would prevent by 
completely removing obsolete branches from the entire repository are 
mergeconflicts which can occur if you merge the revision where the 
obsolete branch was removed from into another branch.


--
Regards,
Stefan Hett

Fwd: Checksum mismatch after resolving conflicts in SVN

[Daniel Shahaf]

(Forwarding to the right list.)

Akshaya wrote on Fri, 02 Jun 2017 00:07 -0700:
> Hi,
> 
> What will be the reason for checksum mismatch error after resolving 
> conflicts in svn?
> After resolving conflicts, commit is successful but ended in checksum 
> mismatch in server.
> 
> Thanks,
> Nachu
> 
> 

svn feature addition?

[Eggler, Ron (GE Energy Connections)]

[snip]
> > -When you do svn commit, instead of automatically submitting all
> > changed files in the directory, in the dialog where you enter the
> > commit message (if -m flag is not used), is there a feature to uncheck
> > any files that should not be committed/select files to be committed?
> 
> With the commandline client that's not possible at the moment (GUI
> clients might offer this in their commit dialog). Would be nice though. I
> guess the UI for 'svn' might be to edit the stuff below "--This line, and
> those below, will be ignored--" in your editor that comes up for the commit
> message.
> 
> I did some archaeology and found an old discussion about this [1]. It got
> some support, but it seems not enough to eventually implement it.
> In that thread, Karl Fogel hinted there was a closed issue and earlier dev@
> discussion about it, which I found here [2] (issue #1295) and here [3].
> 
> The issue also refers to a patch by Mark Grosberg ([4], [5]). His last patch
> submission ([5]) contains a long discussion which reads a bit "bikesheddy".
> Eventually it seems the discussion died and the patch did not get
> committed. (If you search the dev@ archives for 1295 there are earlier
> iterations of the patch which contain some more discussion).
> 
> Maybe that last patch can be brought back to life, and re-discussed?
> 
> > -Is there an option to inspect each file further line-by-line for
> > lines  that have changed to either be selected or excluded from the
> commit?
> 
> Ah, now that's an interesting feature that I also miss sometimes. I listed it
> on the whiteboard during the svn hackathon in 2015 [6], I referred to it as
> "partial commit". It's not possible right now with "core svn", but
> TortoiseSVN has implemented a way to do this with what they call "restore
> after commit" [7].
> 
> I think it would be great to have such a feature in SVN itself.
> 
> For some more background, it has been discussed before a couple of times
> on our lists ([8], [9]), and on StackOverflow ([10], [11]).
> Someone even seems to have implemented in a script something similar to
> the TSVN feature [12].
> 
> > I am interested to potentially work on patches that would extend svn
> > with the above functionality if not present already, does anyone know?
> > It seems like these options would be really useful…
> 
> I think it would be great if you could work on this. We're mostly a
> volunteer-driven project these days, so helping hands are always welcome.
> If you want to discuss specs or design, or start writing / discussing patches,
> it's best to bring those to the dev@ mailinglist (and take a look at our
> Community Guide [13]).
> 
> 
> [1] https://svn.haxx.se/users/archive-2005-06/0557.shtml
> 
> [2] https://issues.apache.org/jira/browse/SVN-1295 (Ability to edit the list
> of files being commited)
> 
> [3] https://svn.haxx.se/dev/archive-2002-01/0715.shtml
> 
> [4] https://svn.haxx.se/dev/archive-2003-05/0709.shtml
> 
> [5] https://svn.haxx.se/dev/archive-2003-05/0904.shtml
> 
> [6] https://svn.haxx.se/dev/archive-2015-09/0187.shtml -- see "( partial
> commit (one hunk out of many) (-> TortoiseSVN?) )"
> 
> [7] https://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-
> commit.html#tsvn-dug-commit-restore
> 
> [8] https://svn.haxx.se/dev/archive-2006-07/0817.shtml
> 
> [9] https://svn.haxx.se/users/archive-2010-01/0287.shtml
> 
> [10] https://stackoverflow.com/questions/75809/partial-commits-with-
> subversion
> 
> [11] https://stackoverflow.com/questions/314132/is-there-some-way-to-
> commit-a-file-partially-in-tortoisesvn
> 
> [12] http://webstaff.itn.liu.se/~karlu20/div/blog/2013-05-
> 31_SVNPartialCommit.php
> 
> [13] http://subversion.apache.org/docs/community-guide/
> 
Your response is packed with very interesting information and resources, it 
will take me some time to work through all of it but I'm definitely interested 
in a follow up.
Thanks Johan!
-- 
Ron

Unsubscribe from GE's commercial electronic messages: 
http://sc.ge.com/*casl-unsubscribe 
Désabonner des messages électroniques commerciaux de GE: 
http://sc.ge.com/*lcap-desabonnement

RE: svn feature addition?

[Andrew Reedick]

> From: Eggler, Ron (GE Energy Connections) [mailto:ron.egg...@ge.com] 
> Sent: Thursday, June 1, 2017 7:44 PM
> To: users@subversion.apache.org
> Subject: svn feature addition?
>
> Hi There,
>
> I am looking for the following features in svn:
> - When you do svn commit, instead of automatically submitting all changed 
> files in the directory, in the dialog where you enter the commit message (if 
> -m flag is not used), is there a feature to uncheck any files that should not 
> be committed/select files to be committed? 
> - Is there an option to inspect each file further line-by-line for lines  
> that have changed to either be selected or excluded from the commit?
> I am interested to potentially work on patches that would extend svn with the 
> above functionality if not present already, does anyone know? It seems like 
> these options would be really useful.

What about working on a (temp) branch and then selectively merging what you 
want over?

Steps would be:
Make temp branch
Switch to temp branch
Commit all
Switch to main branch 
Selectively merge files/lines from temp to main
Commit main.
"Copy merge" from temp to main to overwrite workspace with stuff from temp in 
order to recreate modified files (i.e. files that you only merged a few lines 
from) that existed initially.   
Rm temp branch
Keep working.

Most of that should be scriptable.

Re: Is it safe to remove deleted and no longer used branches from the svn:mergeinfo property?

[Mark Phippard]

Actually, this is the newer tool I was thinking of:

http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-mergeinfo-normalizer/

Mark

On Fri, Jun 2, 2017 at 8:46 AM, Mark Phippard  wrote:

> Have you seen this script?
>
> http://svn.apache.org/repos/asf/subversion/trunk/tools/
> client-side/mergeinfo-sanitizer.py
>
> I believe it does this though I have never tried it.
>
> Mark
>
>
>
> On Wed, May 31, 2017 at 11:18 AM, Alfred von Campe 
> wrote:
>
>> After many years of development, we have over 100 entries in the
>> svn:mergeinfo property of our trunk.  I am thinking about manually editing
>> the property to remove entries for all branches that have been deleted or
>> are no longer used (and should be deleted).  I am hoping that once I merge
>> trunk into the other active branches, the cleanup of that property will
>> also propagate to the other branches.
>>
>> So my questions are:
>>
>>
>>- Is this safe to do?
>>- Will the changes to the properly be merged to all other branches
>>over time as one would expect?
>>
>>
>> Thanks,
>> Alfred
>>
>>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Is it safe to remove deleted and no longer used branches from the svn:mergeinfo property?

[Mark Phippard]

Have you seen this script?

http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/mergeinfo-sanitizer.py

I believe it does this though I have never tried it.

Mark



On Wed, May 31, 2017 at 11:18 AM, Alfred von Campe 
wrote:

> After many years of development, we have over 100 entries in the
> svn:mergeinfo property of our trunk.  I am thinking about manually editing
> the property to remove entries for all branches that have been deleted or
> are no longer used (and should be deleted).  I am hoping that once I merge
> trunk into the other active branches, the cleanup of that property will
> also propagate to the other branches.
>
> So my questions are:
>
>
>- Is this safe to do?
>- Will the changes to the properly be merged to all other branches
>over time as one would expect?
>
>
> Thanks,
> Alfred
>
>


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: Is it safe to remove deleted and no longer used branches from the svn:mergeinfo property?

[Cooke, Mark]

> -Original Message-
> From: Alfred von Campe [mailto:alf...@von-campe.com]
> Sent: 02 June 2017 13:40
> 
> On Jun 2, 2017, at 8:25, Nico Kadel-Garcia wrote:
> 
> > I suspect you're going to hurt yourself if you try this sort of stunt.
> > Not that it might not work in theory for some cases, but it's not
> > tested and is against the basic "never, never, never, and did I
> > mention never alter history" approach to Subversion.
> 
> Why?  The svn:mergeinfo property just kept track of what revisions have
> been merged from a given branch.  If I delete the branch the information
> is useless, but there is no automatic cleanup of that property.

How did you "delete the branch"?  Unless you performed a dump/filter/load then 
they are all still there, in all those revisions referenced by the merge info 
property... Hence the information is still valid.

I seem to remember that new commands (or a script) are available to try to 
consolidate svn:mergeinfo, have you seen or tried any of those?

> > What I think you *can* do is an "svnadmin dump | svndumpfilter exclude
> > (obsolete branches) | svnadmin load" to another Subversion repo, and
> > switch to that repo to have a modified history.
> 
> I don’t want to alter history.  I want the older branches around so they
> can be browsed and inspected for history.  I just want to clean up the
> svn:mergeinfo property so it’s easier to read.
> 
> I would love for one of the Subversion developers to chime in here...
> 
> Alfred

(I'm not a svn dev)

~ Mark C

Re: Is it safe to remove deleted and no longer used branches from the svn:mergeinfo property?

[Alfred von Campe]

On Jun 2, 2017, at 8:25, Nico Kadel-Garcia wrote:

> I suspect you're going to hurt yourself if you try this sort of stunt.
> Not that it might not work in theory for some cases, but it's not
> tested and is against the basic "never, never, never, and did I
> mention never alter history" approach to Subversion.

Why?  The svn:mergeinfo property just kept track of what revisions have
been merged from a given branch.  If I delete the branch the information
is useless, but there is no automatic cleanup of that property.
 
> What I think you *can* do is an "svnadmin dump | svndumpfilter exclude
> (obsolete branches) | svnadmin load" to another Subversion repo, and
> switch to that repo to have a modified history.

I don’t want to alter history.  I want the older branches around so they
can be browsed and inspected for history.  I just want to clean up the
svn:mergeinfo property so it’s easier to read.

I would love for one of the Subversion developers to chime in here...

Alfred

Re: Is it safe to remove deleted and no longer used branches from the svn:mergeinfo property?

[Nico Kadel-Garcia]

On Fri, Jun 2, 2017 at 7:15 AM, Alfred von Campe  wrote:
> On May 31, 2017, at 11:18, I wrote:
>
> After many years of development, we have over 100 entries in the
> svn:mergeinfo property of our trunk.  I am thinking about manually editing
> the property to remove entries for all branches that have been deleted or
> are no longer used (and should be deleted).  I am hoping that once I merge
> trunk into the other active branches, the cleanup of that property will also
> propagate to the other branches.
>
> So my questions are:
>
> Is this safe to do?
> Will the changes to the properly be merged to all other branches over time
> as one would expect?
>
>
> Has anyone ever done this?  Are there any negative repercussions?  Inquiring
> minds (well, maybe it’s just me) want to know…
>
> Alfred

I suspect you're going to hurt yourself if you try this sort of stunt.
Not that it might not work in theory for some cases, but it's not
tested and is against the basic "never, never, never, and did I
mention never alter history" approach to Subversion.

What I think you *can* do is an "svnadmin dump | svndumpfilter exclude
(obsolete branches) | svnadmin load" to another Subversion repo, and
switch to that repo to have a modified history. That's the only
officially supported way to flush obsolete content. There are some
alternatives that I've personally found effective, that are not so
well supported. Using "git-svn" to get the content to a git repo,
deleting content *there*, running a "git gc --aggressive" to clear
content, and then pushing the content back up to another Subversion
server has been effective for me. But it tends to lose svn:properties
settings, and it makes many Subversion admins twitch and shudder and
break out in hives when they realize you're using git to provide
features that violate the basic "never delete  history" of Subversion
design philosophy.

Re: Is it safe to remove deleted and no longer used branches from the svn:mergeinfo property?

[Alfred von Campe]

On May 31, 2017, at 11:18, I wrote:

> After many years of development, we have over 100 entries in the 
> svn:mergeinfo property of our trunk.  I am thinking about manually editing 
> the property to remove entries for all branches that have been deleted or are 
> no longer used (and should be deleted).  I am hoping that once I merge trunk 
> into the other active branches, the cleanup of that property will also 
> propagate to the other branches.
> 
> So my questions are:
> 
> Is this safe to do?
> Will the changes to the properly be merged to all other branches over time as 
> one would expect?

Has anyone ever done this?  Are there any negative repercussions?  Inquiring 
minds (well, maybe it’s just me) want to know…

Alfred

Re: svn feature addition?

[Johan Corveleyn]

On Fri, Jun 2, 2017 at 1:43 AM, Eggler, Ron (GE Energy Connections)
 wrote:
> Hi There,
>
> I am looking for the following features in svn:
>
> -When you do svn commit, instead of automatically submitting all
> changed files in the directory, in the dialog where you enter the commit
> message (if -m flag is not used), is there a feature to uncheck any files
> that should not be committed/select files to be committed?

With the commandline client that's not possible at the moment (GUI
clients might offer this in their commit dialog). Would be nice
though. I guess the UI for 'svn' might be to edit the stuff below
"--This line, and those below, will be ignored--" in your editor that
comes up for the commit message.

I did some archaeology and found an old discussion about this [1]. It
got some support, but it seems not enough to eventually implement it.
In that thread, Karl Fogel hinted there was a closed issue and earlier
dev@ discussion about it, which I found here [2] (issue #1295) and
here [3].

The issue also refers to a patch by Mark Grosberg ([4], [5]). His last
patch submission ([5]) contains a long discussion which reads a bit
"bikesheddy". Eventually it seems the discussion died and the patch
did not get committed. (If you search the dev@ archives for 1295 there
are earlier iterations of the patch which contain some more
discussion).

Maybe that last patch can be brought back to life, and re-discussed?

> -Is there an option to inspect each file further line-by-line for
> lines  that have changed to either be selected or excluded from the commit?

Ah, now that's an interesting feature that I also miss sometimes. I
listed it on the whiteboard during the svn hackathon in 2015 [6], I
referred to it as "partial commit". It's not possible right now with
"core svn", but TortoiseSVN has implemented a way to do this with what
they call "restore after commit" [7].

I think it would be great to have such a feature in SVN itself.

For some more background, it has been discussed before a couple of
times on our lists ([8], [9]), and on StackOverflow ([10], [11]).
Someone even seems to have implemented in a script something similar
to the TSVN feature [12].

> I am interested to potentially work on patches that would extend svn with
> the above functionality if not present already, does anyone know? It seems
> like these options would be really useful…

I think it would be great if you could work on this. We're mostly a
volunteer-driven project these days, so helping hands are always
welcome. If you want to discuss specs or design, or start writing /
discussing patches, it's best to bring those to the dev@ mailinglist
(and take a look at our Community Guide [13]).


[1] https://svn.haxx.se/users/archive-2005-06/0557.shtml

[2] https://issues.apache.org/jira/browse/SVN-1295 (Ability to edit
the list of files being commited)

[3] https://svn.haxx.se/dev/archive-2002-01/0715.shtml

[4] https://svn.haxx.se/dev/archive-2003-05/0709.shtml

[5] https://svn.haxx.se/dev/archive-2003-05/0904.shtml

[6] https://svn.haxx.se/dev/archive-2015-09/0187.shtml -- see "(
partial commit (one hunk out of many) (-> TortoiseSVN?) )"

[7] 
https://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-commit.html#tsvn-dug-commit-restore

[8] https://svn.haxx.se/dev/archive-2006-07/0817.shtml

[9] https://svn.haxx.se/users/archive-2010-01/0287.shtml

[10] https://stackoverflow.com/questions/75809/partial-commits-with-subversion

[11] 
https://stackoverflow.com/questions/314132/is-there-some-way-to-commit-a-file-partially-in-tortoisesvn

[12] 
http://webstaff.itn.liu.se/~karlu20/div/blog/2013-05-31_SVNPartialCommit.php

[13] http://subversion.apache.org/docs/community-guide/

-- 
Johan
(Going for the record of most footnotes in an svn-mailinglist-post)

Re: Checksum mismatch after resolving conflicts in SVN

[Johan Corveleyn]

[ Rerouting this to the users@subversion.apache.org mailinglist (bcc:
subversion-developm...@googlegroups.com) --- users@s.a.o is the
primary channel of the Apache Subversion project for users. More below
... ]

On Fri, Jun 2, 2017 at 9:07 AM, Akshaya  wrote:
> Hi,
>
> What will be the reason for checksum mismatch error after resolving
> conflicts in svn?
> After resolving conflicts, commit is successful but ended in checksum
> mismatch in server.

General answer: that shouldn't happen.
But you've provided very little detail, so it's hard to give further
help. What version of svn are you using on the client (and which OS),
and what version of svn on the server? What were the exact commands
you did, and the exact error message? Can you reproduce the problem
(if so, steps to reproduce?)?

-- 
Johan