You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Gunnar Dalsnes <ha...@online.no> on 2008/09/03 21:33:03 UTC
mergeinfo annoyance
Hi,
I really don't like the new mergeinfo property in 1.5. I merge a
revision and I get a bunch of unrelated propchanges in (to me) unrelated
files and folders?!? Some of my colleges consequently revert\don't
commit those changes, they didn't change those files\folders so I fully
understand.
But why is this internal information leaking out to the user? This is
purely an internal "thing" and the server should do this automatically.
I don't even want to see those propchanges in the log (unless i specify
I want to see them).
Is it just me or has subversion gone mental?
Gunnar.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Neels Hofmeyr <ne...@elego.de>.
Gunnar Dalsnes wrote:
> Yes I agree, propchanges in the log etc. is really annoying but I want
> go further: equally annoying is propchanges during merge\commit: I merge
> a revision and I get a bunch of unrelated propchanges in (to me)
> unrelated files and folders (typically propchange on some subfolders,
> sometimes propchange on the root folder and often propdelete on misc
> unrelated files\folders). Some of my colleges consequently revert\don't
> commit those changes, they didn't change those files\folders so I fully
> understand. But why is this internal information leaking out to the
> users? This is purely an internal "thing" and the server should do this
> automatically! When I merge some files in a folder I expect that when I
> commit that folder, all changes are included, but now I must always
> commit the whole tree to include those propchanges spread around
> everywhere. Not good. The correct thing to do would be to make this
> invisible on the client and have the server do it automatically.
Hi Gunnar,
properties are a generic tool; you can also create your own properties on
files and directories and version them. This generic tool is, sort of
additionally, used by subversion itself, "internally". That's the problem.
A better way to deal with the problem you and others described is to
identify those "internal" properties that cause the users trouble and
provide a choice to omit these in the output.
Now, you argue, showing these "internal" property changes should be off by
default; I agree. Let's see what the others think:
The argument in another branch of this thread is that svn:mergeinfo is in
particular an annoying property to "innocent" users. Mark Phippard wants to
stop using properties for merge info altogether, and Hyrum K. Wright says:
"
I'm currently investigating a generic '--ignore-prop' switch, initially for 'svn
st'. It is being written in such a way that we could easily alias
'--ignore-mergeinfo' or '--forget-merges' or
'--dont-get-in-my-way-i'm-trying-to-do-real-work' to mean '--ignore-prop
svn:mergeinfo'. I hope to have a proof-of-concept patch done in a few days.
-Hyrum
"
I guess any one of these should eventually be exactly what you need ...
coming soon.
Thanks for your input!
~Neels
(btw, let's rather continue replying on the *other* branches of this thread
instead of this one.)
> And
> showing svn:mergeinfo logs should default to off, making this initially
> invisible.
>
> Gunnar.
>
>> In using merge tracking with 1.5.x and other branches, I've
>> occasionally been
>> annoyed by the fact that mergeinfo mods can often overshadow the meat
>> of a
>> change. I'd like to add a '--no-props' flag to 'log', 'st', and 'diff'
>> which
>> would simply cause the subcommand to ignore property changes. It
>> wouldn't be
>> the default, but it would clean up output and make using merge
>> tracking a bit
>> easier.
>>
>> I envision '--no-props' to be an all-or-nothing measure, initially,
>> but we if
>> the demand was there, we could further expand it to '--without-prop
>> FOO' which
>> would only omit changes to property FOO.
>>
>> Thoughts?
>>
>> -Hyrum
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Gunnar Dalsnes <ha...@online.no>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Stefan Sperling wrote:
<blockquote cite="mid:20080904095328.GA1659@ted.stsp.name" type="cite">
<pre wrap="">On Thu, Sep 04, 2008 at 01:42:30AM +0200, Gunnar Dalsnes wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Yes I agree, propchanges in the log etc. is really annoying but I want
go further: equally annoying is propchanges during merge\commit: I merge
a revision and I get a bunch of unrelated propchanges in (to me)
unrelated files and folders (typically propchange on some subfolders,
sometimes propchange on the root folder and often propdelete on misc
unrelated files\folders).
</pre>
</blockquote>
<pre wrap=""><!---->
That's because mergeinfo is stored in properties.
That's the way it currently is. The only way of fixing that
would be to store mergeinfo somewhere else.
</pre>
</blockquote>
It's not fundamentally wrong to use props, as long as the handling is
special:<br>
-don't show mergeinfo propchanges on the client and in logs\diffs<br>
-automatically include related mergeinfo propchanges when
commiting\reverting\etc. the "real" files<br>
<blockquote cite="mid:20080904095328.GA1659@ted.stsp.name" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Some of my colleges consequently revert\don't
commit those changes, they didn't change those files\folders so I fully
understand.
</pre>
</blockquote>
<pre wrap=""><!---->
That's wrong. Your colleagues should _not_ omit mergeinfo property
changes from commits! If they omit these properties from commits,
they are not using Subversion as intended.
Users don't need to understand these properties. They just need to
know they exist, and that they should *always* commit any changes
to these properties which show up in their working copies alongside
their own changes.
</pre>
</blockquote>
Yes, lets put the responsibility on the individual user (famous last
words?).<br>
IMO, this is a blocker: if a user forget to commit some propchanges, we
may be worse off than without merge tracking since we now rely on this
to "just work" and don't review the merges as closely as before.<br>
<blockquote cite="mid:20080904095328.GA1659@ted.stsp.name" type="cite">
<blockquote type="cite">
<pre wrap="">When I merge some files in a folder I expect that when I
commit that folder, all changes are included, but now I must always
commit the whole tree to include those propchanges spread around
everywhere.
</pre>
</blockquote>
<pre wrap=""><!---->
That is a perfectly understandable point of view.
The tool should just work.
But in order to just work, the tool has to manage a certain amount
of information for you. If you don't let it do that, or if you interfere
with that, then you are not using the tool as intended.
</pre>
</blockquote>
When the tool rely on me to work correctly, then it hardly "just work".<br>
<blockquote cite="mid:20080904095328.GA1659@ted.stsp.name" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Not good. The correct thing to do would be to make this
invisible on the client and have the server do it automatically. And
showing <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a> logs should default to off, making this initially
invisible.
</pre>
</blockquote>
<pre wrap=""><!---->
This is a conundrum.
If we didn't show these properties by default, users would likely
end up not always committing changes the client has made to them.
</pre>
</blockquote>
Those propchanges should off course be committed automatically when i
commit the merged file that caused the propchanges.<br>
<blockquote cite="mid:20080904095328.GA1659@ted.stsp.name" type="cite">
<pre wrap="">
But for now, you will have to live with mergeinfo properties.
A lot of work has gone into the merge tracking functionality.
It's not a feature that is simple to implement. Changing something
as fundamental as the way mergeinfo is stored is certainly a good
amount of work.
So, I'm afraid I would not expect such a change to be made soon, if at all.
</pre>
</blockquote>
I'm sorry to hear that.<br>
<br>
Gunnar.<br>
<blockquote cite="mid:20080904095328.GA1659@ted.stsp.name" type="cite">
<pre wrap="">
Stefan
</pre>
</blockquote>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-09-07 22:06:33 +0200, Stefan Sperling wrote:
> is this the thread you were referring to?
>
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=142246
>
> Date: Wed, 27 Aug 2008 17:00:26 +0400
> From: Danil Shopyrin <da...@visualsvn.com>
> Content-Type: text/plain; charset=ISO-8859-1
> Subject: Useless explicit mergeinfo records
Yes, and the other one I mentioned:
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=81655
"svn merge" scans the whole wc and deletes svn:mergeinfo properties
In both cases, this is about mergeinfo elision, IIRC.
Is there any reason that elision isn't restricted to files that are
concerned by the merge?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Sep 07, 2008 at 09:45:02PM +0200, Stefan Sperling wrote:
> On Sun, Sep 07, 2008 at 03:19:05PM +0200, Vincent Lefevre wrote:
> > They don't need to understand them, but they currently are affected by
> > them directly. If write access has been restricted on these unrelated
> > files (see the other thread), this even means that some users can no
> > longer commit!
>
> That is indeed a good point. I'll try to find "the other thread"
> to read up on this. BTW, it would be kind if you took the time to provide
> a link (or at least a subject line) if you refer to other threads.
Vincent,
is this the thread you were referring to?
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=142246
Date: Wed, 27 Aug 2008 17:00:26 +0400
From: Danil Shopyrin <da...@visualsvn.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Useless explicit mergeinfo records
Thanks,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-09-07 21:45:02 +0200, Stefan Sperling wrote:
> > > By the way, I would argue that always committing the whole working
> > > copy in one go is good practice anyway.
> >
> > I don't see this as good practice. The user may want to work on
> > different sets of files.
>
> ... in different working copies. ;)
Most of my files are managed by Subversion. I currently have a
working copy "wd", the remaining of my home being generated files
(and temporary files). It is important that I can do global things
like "svn update" and "svn status" at the root, in particular
because I have 5 accounts I use regularly.
> But I guess you'd mainly want to disable merge tracking to avoid
> running into problems with the design or implementation, right?
Yes. Now, this doesn't occur very frequently on my files (but
I don't need merge tracking there).
> Apart from the authz / svn:mergeinfo commit problem, what other
> problems are you seeing?
No other problems.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Gunnar Dalsnes <ha...@online.no>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Stefan Sperling wrote:
<blockquote cite="mid:20080907194502.GA2587@ted.stsp.name" type="cite">
<pre wrap="">On Sun, Sep 07, 2008 at 03:19:05PM +0200, Vincent Lefevre wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 2008-09-04 11:53:29 +0200, Stefan Sperling wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Sep 04, 2008 at 01:42:30AM +0200, Gunnar Dalsnes wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Some of my colleges consequently revert\don't commit those
changes, they didn't change those files\folders so I fully
understand.
</pre>
</blockquote>
<pre wrap="">That's wrong. Your colleagues should _not_ omit mergeinfo property
changes from commits! If they omit these properties from commits,
they are not using Subversion as intended.
</pre>
</blockquote>
<pre wrap="">No, if Subversion modified <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a> on *unrelated* files, his
colleagues ignore these files because Subversion didn't behave as
intended.
</pre>
</blockquote>
<pre wrap=""><!---->
I agree that if totally unrelated files get their mergeinfo
modified, it's probably a bug.
IIRC there was no mention of that before in this thread, though.
</pre>
<br>
</blockquote>
Totally unrelated files\folders are not strictly modified but got their
<a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a> deleted (but deletion is a modification too:-)).
Nevertheless, very annoying and to me meaningless thingamabobs. Here is
an example of a merge of one revision:<br>
<br>
/branches/2.3
Added: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a> "Merged /trunk:r1033"<br>
/branches/2.3/src/Build/settings.bat
(changed & merged)<br>
/branches/2.3/src/Plugins/Registration/ALPFeedstore/RegisterSilo/Model/FeedstoreDataTable.cs
Deleted: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a><br>
/branches/2.3/src/Plugins/Registration/ALPFeedstore/Resources/forlager_16x16.gif
Deleted: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a><br>
/branches/2.3/src/Plugins/Registration/ALPFeedstore/Resources/forlager_20x20.gif
Deleted: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a><br>
/branches/2.3/src/Plugins/Registration/ALPFeedstore/Resources/forsilo_16x16.gif
Deleted: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a><br>
/branches/2.3/src/Plugins/Registration/ALPFeedstore/Resources/forsilo_20x20.gif
Deleted: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a><br>
/branches/2.3/src/Plugins/Registration/BLDataMappers/Feed
Deleted: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a><br>
/branches/2.3/src/Plugins/Registration/BLPMyActivities/DMHatching.cs
Deleted: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a><br>
/branches/2.3/src/VPA Framework/AFSBLServer/AFSBLServer.cs
(changed & merged)<br>
/branches/2.3/src/VPA Framework/AFSClient/View/frmLogin.cs
(changed & merged)<br>
/branches/2.3/src/VPA Framework/AFSClient/View/frmMain.cs
(changed & merged)<br>
/branches/2.3/src/VPA
Framework/VPADALClasses/Feed/DAFeedDeliveryNotes.cs
Deleted: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a><br>
/branches/2.3/src/VPA
Framework/VPADALClasses/System/DASnapshotIsolation.cs
(changed & merged)<br>
/branches/2.3/src/VPA Framework/VPAEntities/Settings/VPASettings.cs
(changed & merged)<br>
/branches/2.3/src/VPA Framework/VPAEntities/VPATransaction.cs
Deleted: <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a><br>
<br>
Damn uUgly.<br>
<br>
"Its not a bug, its a feature"<br>
<br>
Gunnar.
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Sep 07, 2008 at 03:19:05PM +0200, Vincent Lefevre wrote:
> On 2008-09-04 11:53:29 +0200, Stefan Sperling wrote:
> > On Thu, Sep 04, 2008 at 01:42:30AM +0200, Gunnar Dalsnes wrote:
> > > Some of my colleges consequently revert\don't commit those
> > > changes, they didn't change those files\folders so I fully
> > > understand.
> >
> > That's wrong. Your colleagues should _not_ omit mergeinfo property
> > changes from commits! If they omit these properties from commits,
> > they are not using Subversion as intended.
>
> No, if Subversion modified svn:mergeinfo on *unrelated* files, his
> colleagues ignore these files because Subversion didn't behave as
> intended.
I agree that if totally unrelated files get their mergeinfo
modified, it's probably a bug.
IIRC there was no mention of that before in this thread, though.
As far as I understood, mergeinfo may pop up in unexpected
places sometimes, due to mergeinfo inheritance.
My understanding of this does not go very deep though. If you
or someone else can enlighten me, please do so :)
In fact, I may have to read pburba's blog post again to get up to speed:
http://www.collab.net/community/subversion/articles/merge-info.html
(I read it all once but forgot most of it again at this point.)
> > Users don't need to understand these properties.
>
> They don't need to understand them, but they currently are affected by
> them directly. If write access has been restricted on these unrelated
> files (see the other thread), this even means that some users can no
> longer commit!
That is indeed a good point. I'll try to find "the other thread"
to read up on this. BTW, it would be kind if you took the time to provide
a link (or at least a subject line) if you refer to other threads.
> > Well, "the server should do this automatically" may be easier said
> > than done. If there was no reason for client-side state information
> > about mergeinfo, we would not have it in the first place.
>
> This can also mean that the algorithm that modifies these properties
> is wrong.
Yes. It would help if you could also spell out the flaws you're seeing
in a manner that's suitable to pinpoint the exact problems in the
design/code.
> > By the way, I would argue that always committing the whole working
> > copy in one go is good practice anyway.
>
> I don't see this as good practice. The user may want to work on
> different sets of files.
... in different working copies. ;)
This is a bikeshed issue. Some people like working that way, some don't.
> > So, I'm afraid I would not expect such a change to be made soon, if
> > at all.
>
> How about an option to disable merge tracking?
For new projects: svnadmin create --pre-1.5-compatible /path/to/repos
Of course that does not help much with existing projects in 1.5 format.
I don't know if a knob to disable merge tracking has been suggested
before, but I don't think there would be a problem with a knob that
disables it. No idea now hard that would be to implement, though.
But I guess you'd mainly want to disable merge tracking to avoid running
into problems with the design or implementation, right? Apart from
the authz / svn:mergeinfo commit problem, what other problems are
you seeing?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-09-04 11:53:29 +0200, Stefan Sperling wrote:
> On Thu, Sep 04, 2008 at 01:42:30AM +0200, Gunnar Dalsnes wrote:
> > Some of my colleges consequently revert\don't commit those
> > changes, they didn't change those files\folders so I fully
> > understand.
>
> That's wrong. Your colleagues should _not_ omit mergeinfo property
> changes from commits! If they omit these properties from commits,
> they are not using Subversion as intended.
No, if Subversion modified svn:mergeinfo on *unrelated* files, his
colleagues ignore these files because Subversion didn't behave as
intended.
> Users don't need to understand these properties.
They don't need to understand them, but they currently are affected by
them directly. If write access has been restricted on these unrelated
files (see the other thread), this even means that some users can no
longer commit!
> Well, "the server should do this automatically" may be easier said
> than done. If there was no reason for client-side state information
> about mergeinfo, we would not have it in the first place.
This can also mean that the algorithm that modifies these properties
is wrong.
> By the way, I would argue that always committing the whole working
> copy in one go is good practice anyway.
I don't see this as good practice. The user may want to work on
different sets of files.
> If you have one set of changes in one part of your working copy and
> another unrelated set of changes in another, why not organise your
> work so that each set of related changes sits in their own working
> copy?
Yes, let's go back to RCS!
> So, I'm afraid I would not expect such a change to be made soon, if
> at all.
How about an option to disable merge tracking?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Sep 04, 2008 at 01:42:30AM +0200, Gunnar Dalsnes wrote:
> Yes I agree, propchanges in the log etc. is really annoying but I want
> go further: equally annoying is propchanges during merge\commit: I merge
> a revision and I get a bunch of unrelated propchanges in (to me)
> unrelated files and folders (typically propchange on some subfolders,
> sometimes propchange on the root folder and often propdelete on misc
> unrelated files\folders).
That's because mergeinfo is stored in properties.
That's the way it currently is. The only way of fixing that
would be to store mergeinfo somewhere else.
> Some of my colleges consequently revert\don't
> commit those changes, they didn't change those files\folders so I fully
> understand.
That's wrong. Your colleagues should _not_ omit mergeinfo property
changes from commits! If they omit these properties from commits,
they are not using Subversion as intended.
Users don't need to understand these properties. They just need to
know they exist, and that they should *always* commit any changes
to these properties which show up in their working copies alongside
their own changes.
> But why is this internal information leaking out to the
> users? This is purely an internal "thing" and the server should do this
> automatically!
Well, "the server should do this automatically" may be easier said
than done. If there was no reason for client-side state information
about mergeinfo, we would not have it in the first place.
> When I merge some files in a folder I expect that when I
> commit that folder, all changes are included, but now I must always
> commit the whole tree to include those propchanges spread around
> everywhere.
That is a perfectly understandable point of view.
The tool should just work.
But in order to just work, the tool has to manage a certain amount
of information for you. If you don't let it do that, or if you interfere
with that, then you are not using the tool as intended.
You don't delete your .svn directories either, even though you
can see them in the filesystem, right?
By the way, I would argue that always committing the whole working
copy in one go is good practice anyway.
If you have one set of changes in one part of your working copy and
another unrelated set of changes in another, why not organise your
work so that each set of related changes sits in their own working copy?
If your working copies are so large that you run out of disk
when creating a few of them, either get more disk space or
use sparse checkouts to reduce the size of your working copies.
> Not good. The correct thing to do would be to make this
> invisible on the client and have the server do it automatically. And
> showing svn:mergeinfo logs should default to off, making this initially
> invisible.
This is a conundrum.
If we didn't show these properties by default, users would likely
end up not always committing changes the client has made to them.
And then these users would starting complaining when merge tracking
fails to work.
But on the other hand I agree with your point that presenting merge
tracking data to users can be irritating.
I would not object to not using properties to store mergeinfo
if we can come up with a better way of storing it.
But for now, you will have to live with mergeinfo properties.
A lot of work has gone into the merge tracking functionality.
It's not a feature that is simple to implement. Changing something
as fundamental as the way mergeinfo is stored is certainly a good
amount of work.
So, I'm afraid I would not expect such a change to be made soon, if at all.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal: --no-props switch for 'log', 'st' and 'diff'
Posted by Gunnar Dalsnes <ha...@online.no>.
Yes I agree, propchanges in the log etc. is really annoying but I want
go further: equally annoying is propchanges during merge\commit: I merge
a revision and I get a bunch of unrelated propchanges in (to me)
unrelated files and folders (typically propchange on some subfolders,
sometimes propchange on the root folder and often propdelete on misc
unrelated files\folders). Some of my colleges consequently revert\don't
commit those changes, they didn't change those files\folders so I fully
understand. But why is this internal information leaking out to the
users? This is purely an internal "thing" and the server should do this
automatically! When I merge some files in a folder I expect that when I
commit that folder, all changes are included, but now I must always
commit the whole tree to include those propchanges spread around
everywhere. Not good. The correct thing to do would be to make this
invisible on the client and have the server do it automatically. And
showing svn:mergeinfo logs should default to off, making this initially
invisible.
Gunnar.
> In using merge tracking with 1.5.x and other branches, I've
> occasionally been
> annoyed by the fact that mergeinfo mods can often overshadow the meat
> of a
> change. I'd like to add a '--no-props' flag to 'log', 'st', and 'diff'
> which
> would simply cause the subcommand to ignore property changes. It
> wouldn't be
> the default, but it would clean up output and make using merge
> tracking a bit
> easier.
>
> I envision '--no-props' to be an all-or-nothing measure, initially,
> but we if
> the demand was there, we could further expand it to '--without-prop
> FOO' which
> would only omit changes to property FOO.
>
> Thoughts?
>
> -Hyrum
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: mergeinfo annoyance
Posted by eg <eg...@gmail.com>.
Gunnar Dalsnes wrote:
> Hi,
>
> I really don't like the new mergeinfo property in 1.5. I merge a
> revision and I get a bunch of unrelated propchanges in (to me) unrelated
> files and folders?!? Some of my colleges consequently revert\don't
> commit those changes, they didn't change those files\folders so I fully
> understand.
>
> But why is this internal information leaking out to the user? This is
> purely an internal "thing" and the server should do this automatically.
> I don't even want to see those propchanges in the log (unless i specify
> I want to see them).
>
> Is it just me or has subversion gone mental?
>
Others share your opinion. There is some discussion on the dev list
right now to change how to control this output for log, st and diff...
For more details, see the thread at:
http://svn.haxx.se/dev/archive-2008-09/0008.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org