Re: How to display the code in my branch without merge changes?
On 10/15/13 6:26 AM, Gabriela Gibson wrote: On 15/10/13 13:24, John Maher wrote: Hi John, Can you explain what you mean by “current version”. When you merge from the trunk you change the current version. So the current version and all versions afterward include the merged changes. Do you mean a version BEFORE the merge? You can pass a revision to the diff command to get the one you want. I want just the current 'net' code I wrote into my branch, minus the merge changes and various versions I tried in the process, ie, a neat version of what diff -r ~/trunk/subversion/ ~/branches/invoke-diff-cmd-feature/subversion/ would show me, supposing that I just have merged the trunk into the branch. So, branch - trunk = net code. I've merged the trunk into the branch a few times now in order to keep it up to date so there is no revision that I could go back to. thanks, Gabriela If you are fully up to date with merges, then you should just be able to diff against trunk.That should show you the differences between your branch and the trunk (net changes). -- Alfred Perlstein
PATCH: keyword expansion 1.8
[[ Adding users@subversion.apache.org ]]
He folks. I am in no way a Subversion expert, however per request I've
taken the FreeBSD patch for adding custom keyword expansion and forward
ported it to what is soon to be Subversion 1.8.
I am wondering if anyone can help me test this or give me some things to
try to ensure that it works properly.
-Alfred
On 2/1/13 7:40 AM, Alfred Perlstein wrote:
[[ bringing in Lev Serebryakov, FreeBSD port maintainer for Subversion ]]
Hello Lev,
Stefan of the Subversion project asked me about bringing in our
keywords patch for subversion 1.8.
I've taken a bit of time and gotten the patch to apply to subversion
trunk (untested).
Can you have a look and let us know what we need to do with regards to
testing or anything else?
Stefan, any suggestions on going forward?
-Alfred
On 2/1/13 8:34 AM, Stefan Sperling wrote:
On Fri, Feb 01, 2013 at 08:01:02AM -0500, Alfred Perlstein wrote:
[[ reply private ]]
First of all, thank you very much for taking the time to explain this.
I've forwarded your response to a few people who are more
knowledgeable about Subversion in our community (John Baldwin /
Peter Wemm) to hopefully get back us on the issue of mergeinfo and
reintegrate.
Thanks!
Regarding the patch:
http://subversion.tigris.org/issues/show_bug.cgi?id=890
I just read this. What can I do to help on this issue?
See the mailing list thread linked from
http://subversion.tigris.org/issues/show_bug.cgi?id=890#desc40
That's the last time the patch got reviewed. It needs to be updated
to Subversion's trunk (to-be-1.8) before it can be committed.
Index: subversion/include/private/svn_subst_private.h
===
--- subversion/include/private/svn_subst_private.h (revision 0)
+++ subversion/include/private/svn_subst_private.h (working copy)
@@ -0,0 +1,68 @@
+/**
+ * @copyright
+ *
+ *Licensed to the Apache Software Foundation (ASF) under one
+ *or more contributor license agreements. See the NOTICE file
+ *distributed with this work for additional information
+ *regarding copyright ownership. The ASF licenses this file
+ *to you under the Apache License, Version 2.0 (the
+ *License); you may not use this file except in compliance
+ *with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *Unless required by applicable law or agreed to in writing,
+ *software distributed under the License is distributed on an
+ *AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ *KIND, either express or implied. See the License for the
+ *specific language governing permissions and limitations
+ *under the License.
+ *
+ * @endcopyright
+ *
+ * @file svn_subst_private.h
+ * @brief Non-public subst utility functions.
+ */
+
+
+#ifndef SVN_SUBST_PRIVATE_H
+#define SVN_SUBST_PRIVATE_H
+
+#include svn_subst.h/* for svn_boolean_t, svn_error_t */
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+/**
+ * Set @a *kw to a new keywords hash filled with the appropriate contents
+ * given a @a keywords_string (the contents of the svn:keywords
+ * property for the file in question), the revision @a rev, the @a url,
+ * the url of the root of the @a repos, the @a date the file was committed
+ * on, and the @a author of the last commit. Any of these can be @c NULL
+ * to indicate that the information is not present, or @c 0 for @a date.
+ *
+ * Hash keys are of type ttconst char */tt.
+ * Hash values are of type ttsvn_string_t */tt.
+ *
+ * All memory is allocated out of @a pool.
+ *
+ * @since New in 1.6
+ */
+svn_error_t *
+svn_subst_build_keywords3(apr_hash_t **kw,
+ const char *keywords_string,
+ const char *rev,
+ const char *url,
+ const char *repos,
+ apr_time_t date,
+ const char *author,
+ apr_pool_t *pool);
+
+
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* SVN_SUBST_PRIVATE_H */
Index: subversion/libsvn_client/cat.c
===
--- subversion/libsvn_client/cat.c (revision 1441445)
+++ subversion/libsvn_client/cat.c (working copy)
@@ -40,6 +40,7 @@
#include svn_private_config.h
#include private/svn_wc_private.h
+#include private/svn_subst_private.h
/*** Code. ***/
@@ -124,12 +125,15 @@
const char *author;
const char *url;
apr_time_t tm;
+ const char *repos;
SVN_ERR(svn_wc__node_get_changed_info(changed_rev, tm, author, wc_ctx,
local_abspath, scratch_pool
Re: FreeBSD project and subversion.
On 1/31/13 12:08 PM, Stefan Sperling wrote: On Thu, Jan 31, 2013 at 10:37:14AM -0500, Alfred Perlstein wrote: FreeBSD has moved to Subversion a few years ago and it's worked very, very well for us. Thanks! That's encouraging to hear. The one area where we are having issues is merging code from project branches back into trunk. The typical workflow is: 1) create project branch. 2) code code code. 3) sync from HEAD (this works great). 4) repeat steps 2+3 until feature is complete. 5) svn diff and apply to head then commit. Is there a way to do 5 automatically? I think the worry is mergeinfo from the project branch coming back into HEAD. Any tips would be appreciated. I've read the FreeBSD svn merging docs some time ago. I'm not sure if changes have been made since, but it was probably an older version of what currently lives at this URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html Back then I was somewhat worried that apparently the person who wrote them didn't really understand much about how merges in Subversion work. There was irrational fear of mergeinfo propagation, to the point where the recommended practice is to remove mergeinfo before commit, which any Subversion user with a clue will know is very wrong (expect in very exceptional circumstances and only if you are equipped with sufficient expertise to deal with the consequences). What surprised me also was a complete lack of mention of the --reintegrate option, which I suspect must be causing quite a lot of grief among FreeBSD developers due to bogus conflicts during merges back into FreeBSD's head branch (i.e. the trunk). We'll need more details to help you in a constructive way, though. Can you provide more details about your steps 1 to 5, i.e. show the exact commands you're running in each step? The repository is public, after all, which will help greatly with identifying and reproducing specific problems. I'm happy to provide input for improving FreeBSD's docs to the point where FreeBSD makes the best possible use of Subversion 1.7's merge implementation, and can also provide some hints as to how future versions of Subversion will improve to make life easier in certain cases. BTW, I went over one of FreeBSD's svn wiki pages a while back, and added answers to open questions on this page: https://wiki.freebsd.org/SubversionMissing Thank you Stefan, So I have two answers here: 1) about mergeinfo It seems as if doing it all at the top can make merges over long haul internet very painful. 2) about reintegrate I've attached the two messages that show what makes FreeBSD gun shy about merges to HEAD. Maybe these issues are resolved, or maybe the developer did something incorrect, or maybe something else entirely different happened. See attached. Thank you, -Alfred ---BeginMessage--- -- John Baldwin ---BeginMessage--- On Friday, June 01, 2012 1:40:29 pm David O'Brien wrote: On Wed, May 16, 2012 at 11:00:48AM -0400, John Baldwin wrote: I more or less don't trust svn merge to DTRT here. This was done with the cpuset branch merge up to HEAD and it broke the log history of many files in HEAD. Specifically how did it break log history? http://svnweb.freebsd.org/base/head/share/man/man4/geom_map.4?view=log You have to walk up to the previous directory in svnweb and go back to change 222812 and then click on geom_map.4 to find its original log. sys/dev/iicbus/ad7417.c was also busted this way. I would just generate a diff and manually apply that to a HEAD checkout and commit that. You could perhaps svn cp over new files from the nand branch to HEAD to preserve their history, but I worry that anything other than diff + patch for existing files risks hosing history. WOAH!! Please lets gain some new experience with 'svn merge' using version 1.7. We do 100's of merges a year at $WORK (with svn 1.6) on a code base 10x that of FreeBSD -- it works. I've never had problems with merging downstream into work branches. I've only seen upstream merges blow up. -- John Baldwin -- This mail is for the internal use of the FreeBSD project committers, and as such is private. This mail may not be published or forwarded outside the FreeBSD committers' group or disclosed to other unauthorised parties without the explicit permission of the author(s). ---End Message--- ---End Message--- ---BeginMessage--- On Friday, February 01, 2013 7:53:57 am Alfred Perlstein wrote: John and Peter, both of you are +inf more knowledgeable about svn than I am. I see we still try to minimize svn mergeinfo from the FAQ (Selecting the Source and Target) http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers- guide/subversion-primer.html#AEN771 I know I've seen some emails explaining the reasoning behind this but I can't find them. What would the effect of bringing mergeinfo to the top be? Possible problems: 1) it would get very large 2) if we
FreeBSD project and subversion.
FreeBSD has moved to Subversion a few years ago and it's worked very, very well for us. The one area where we are having issues is merging code from project branches back into trunk. The typical workflow is: 1) create project branch. 2) code code code. 3) sync from HEAD (this works great). 4) repeat steps 2+3 until feature is complete. 5) svn diff and apply to head then commit. Is there a way to do 5 automatically? I think the worry is mergeinfo from the project branch coming back into HEAD. Any tips would be appreciated. thank you, -Alfred
