You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2008/04/29 10:14:07 UTC
Re: svn commit: r30834 - trunk/www
On Tue, Apr 29, 2008 at 02:36:42AM -0700, stylesen@tigris.org wrote:
> Author: stylesen
> Date: Tue Apr 29 02:36:42 2008
> New Revision: 30834
>
> Log:
> * www/hacking.html
> (release-stabilization): Add a note on adding revisions to a group in STATUS
> file based on - http://svn.haxx.se/dev/archive-2008-04/1207.shtml
>
> Suggested by: hwright
> Reviewed by: arfrever
> Approved by: stsp
>
> Modified:
> trunk/www/hacking.html
>
> Modified: trunk/www/hacking.html
> URL: http://svn.collab.net/viewvc/svn/trunk/www/hacking.html?pathrev=30834&r1=30833&r2=30834
> ==============================================================================
> --- trunk/www/hacking.html Tue Apr 29 00:57:35 2008 (r30833)
> +++ trunk/www/hacking.html Tue Apr 29 02:36:42 2008 (r30834)
> @@ -2730,6 +2730,20 @@ concerns field, and include a url / mess
> if any. You can go back and add the link later if the thread isn't
> available at the time you commit the veto.</p>
>
> +<p>If you add revisions to a group, note that the previous voters have
> +not voted for those revisions, as follows:</p>
> +
> +<pre>
> + * r30643, r30653, r30785
> + Update bash completion script.
> + Votes:
> + +1: arfrever (r30785 only), stylesen
> +</pre>
> +
> +<p>If in case votes have been communicated via IRC or other means,
> +note that in the log message. Some <a href="#obvious-fix">obvious
> +fixes</a> do not require '(rX only)' to be mentioned.</p>
I'd remove the word 'Some' here, because this implies that not all
obvious fixes require this, but it does not explain which.
Let's just have this apply to all obvious fixes instead:
note that in the log message. <a href="#obvious-fix">Obvious
fixes</a> do not require '(rX only)' to be mentioned.</p>
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: svn commit: r30834 - trunk/www
Posted by Senthil Kumaran S <se...@collab.net>.
Hi Stefan,
Stefan Sperling wrote:
> I'd remove the word 'Some' here, because this implies that not all
> obvious fixes require this, but it does not explain which.
>
> Let's just have this apply to all obvious fixes instead:
>
> note that in the log message. <a href="#obvious-fix">Obvious
> fixes</a> do not require '(rX only)' to be mentioned.</p>
Committed in r30836.
Thank You.
--
Senthil Kumaran S
http://www.stylesen.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Redundant mergeinfo changes on subtrees with specialized mergeinfo
Posted by Blair Zajac <bl...@orcaware.com>.
Not related to your post, but please do not reply to an existing thread to start
a new one. See here why:
http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post
Regards,
Blair
Leonardo Fernandes wrote:
> Hi. I just want to discuss a use case which is occurring with us.
> Suppose we have a project structure such as follows:
>
> trunk
> |- moduleA
> |- moduleB
>
> We create a branch by copying trunk to branches/mybranch. Merges can be
> done for the top-level directory (from trunk to branches/mybranch), or
> just for one module (from trunk/moduleA to branches/mybranch/moduleA).
> Sometimes we may even perform a merge on a single file deep in some of
> the modules.
>
> After a few such merges, we have specialized mergeinfo in
> branches/mybranch/moduleA (and in other places as well).
>
> Now suppose we commit a file in trunk/moduleB/file. Now we merge this
> commit into a branches/mybranch working copy. This not only changes the
> file moduleB/file, but also changes the mergeinfo in all subtrees with
> specialized mergeinfo (including moduleA).
>
> Now, as far as I can tell, those changes in moduleB and other unchanged
> files are redundant, since the revision being merged has no changes at
> all to those subtrees. And why should I commit a file/directory
> resulting of a merge, when I am sure it wasn't changed?
> IMHO this confuses the user, makes it difficult spotting the real and
> relevant changes in the list of changed files, and pollutes the logs
> with irrelevant commits to those files.
>
> We are using svn 1.5.0-rc4 and TortoiseSVN as client, if that matters.
>
> Leonardo Fernandes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Redundant mergeinfo changes on subtrees with specialized mergeinfo
Posted by Leonardo Fernandes <le...@outsystems.com>.
Hi. I just want to discuss a use case which is occurring with us.
Suppose we have a project structure such as follows:
trunk
|- moduleA
|- moduleB
We create a branch by copying trunk to branches/mybranch. Merges can be
done for the top-level directory (from trunk to branches/mybranch), or
just for one module (from trunk/moduleA to branches/mybranch/moduleA).
Sometimes we may even perform a merge on a single file deep in some of
the modules.
After a few such merges, we have specialized mergeinfo in
branches/mybranch/moduleA (and in other places as well).
Now suppose we commit a file in trunk/moduleB/file. Now we merge this
commit into a branches/mybranch working copy. This not only changes the
file moduleB/file, but also changes the mergeinfo in all subtrees with
specialized mergeinfo (including moduleA).
Now, as far as I can tell, those changes in moduleB and other unchanged
files are redundant, since the revision being merged has no changes at
all to those subtrees. And why should I commit a file/directory
resulting of a merge, when I am sure it wasn't changed?
IMHO this confuses the user, makes it difficult spotting the real and
relevant changes in the list of changed files, and pollutes the logs
with irrelevant commits to those files.
We are using svn 1.5.0-rc4 and TortoiseSVN as client, if that matters.
Leonardo Fernandes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org