You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Archie Cobbs <ar...@dellroad.org> on 2004/09/26 23:18:53 UTC
[PATCH] 'svnmerge' tool for automating merges
FWIW...
Attached is a tool called "svnmerge" that we're using locally to
automatically track merges from our trunk to branches. It stores the
merged-in revisions as a list in a property on the branch directory.
I know there are other developments in this area in the works, so
this may be of limited value (and I haven't been following this
mailing list so my information is out of date). In any case, it has
proven useful here while more integrated merge tracking is being
worked on.
Here is the help message to give people an idea of how it works:
> Usage:
> svnmerge init [-s] [-v] [-n] [-r revs] [-f file] head
> Initialize merge tracking from "head" on the current working
> directory. "head" is either an URL or a working directory;
> in the latter case, the corresponding URL is used. "revs"
> specifies the already-merged in revisions; it defaults to
> "1-HEAD", where HEAD is the latest revision of "head".
>
> svnmerge avail [-s] [-v] [-l] [-d] [-r revs] [branch-dir]
> Show unmerged revisions available for "branch-dir" as a
> revision list. If revision list "revs" is given, the revisions
> shown will be limited to those also specified in "revs".
> Options specific to this command:
> -l Show corresponding log history instead of revision list
> -d Show corresponding diffs instead of revision list
>
> svnmerge merge [-s] [-v] [-n] [-r revs] [-f file] [branch-dir]
> Merge in revisions specified by "revs" into "branch-dir"
> from the "head" location previously specified by init.
> "revs" is the revision list specifying revisions to merge in.
> Already merged-in revisions will not be merged in again.
> Default for "revs" is "1-HEAD" where HEAD is the latest
> revision of the "head" repository (i.e., merge all available).
>
> Options common to multiple commands:
> -v Verbose mode: output more information about progress
> -s Show subversion commands that make changes
> -n Don't actually change anything, just pretend; implies -s
> -f Write a suitable commit log message into "file"
> -r Specify a revision list, consisting of revision numbers
> and ranges separated by commas, e.g., "534,537-539,540"
>
> "branch-dir" is always a working directory and defaults to ".".
Also, any suggestions or bug fixes are greatly appreciated!
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [PATCH] 'svnmerge' tool for automating merges
Posted by Michael W Thelen <th...@cs.utah.edu>.
Archie Cobbs wrote:
> Attached is a tool called "svnmerge" that we're using locally to
> automatically track merges from our trunk to branches. It stores the
> merged-in revisions as a list in a property on the branch directory.
Thanks! I've filed this as issue 2084:
http://subversion.tigris.org/issues/show_bug.cgi?id=2084
--
Michael W Thelen
It is a mistake to think you can solve any major problems just with
potatoes. -- Douglas Adams
Re: [PATCH] 'svnmerge' tool for automating merges
Posted by Archie Cobbs <ar...@dellroad.org>.
?yvind A. Holm wrote:
> > Attached is a tool called "svnmerge" that we're using locally to
> > automatically track merges from our trunk to branches. It stores the
> > merged-in revisions as a list in a property on the branch directory.
>
> What license are you using for this script? GPL-compatible, hopefully?
> Seems as a nice thing to have in svnutils.
Um, (ahem) sure.. how about BSD style? I added a copyright notice
at the top and updated the version posted here:
http://www.dellroad.org/svnmerge/index
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] 'svnmerge' tool for automating merges
Posted by "Øyvind A. Holm" <su...@sunbase.org>.
On 2004-09-26 18:18:53 Archie Cobbs wrote:
> FWIW...
>
> Attached is a tool called "svnmerge" that we're using locally to
> automatically track merges from our trunk to branches. It stores the
> merged-in revisions as a list in a property on the branch directory.
What license are you using for this script? GPL-compatible, hopefully?
Seems as a nice thing to have in svnutils.
Regards,
Øyvind A. Holm
---------------------
cat /dev/urandom >SCO
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] 'svnmerge' tool for automating merges
Posted by "Bruce A. Mah" <bm...@acm.org>.
On Tue, 2004-09-28 at 12:35, Archie Cobbs wrote:
> > One minor comment so far: You're pretty insistent in check_branch_dir()
> > on having a totally clean WC before doing an init or merge operation.
> > Seems to me you could be a teensy bit more forgiving without sacrificing
> > correctness, I am thinking particularly of the case of unversioned files
> > in the WC such as compiled object files. Maybe use the "-q" option in
> > the second invocation of svn stat?
>
> Yes, I did that because the merge will fail if a file that is added
> in the merge also already exists (unversioned) in the branch tree.
> The workaround is to put such files in svn:ignore. However, I agree
> this is pretty conservative behavior, so maybe just letting the merge
> fail and leaving it up to the user to fix is better.
Yeah, I think that's better. Another possibility might be to warn the
user but proceed anyways. Maybe if "svn status" shows dirty files but
"svn status -q" does not? (Hmmm...that's going to take longer though.)
> On the other hand, having outstanding changes to versioned files (as
> opposed to extra, unversioned files) is a much more serious threat to
> the process.. because you could unwittingly "merge" in a change that
> never existed in the head branch. That's much more important to guard
> against.
Yep, that's definitely a case to be avoided.
> Another thought I had is that it would be nice if it could auto-detect
> any "empty" merges, i.e., commits that don't affect the head branch,
> and go ahead and merge them in. Otherwise, they just clutter up the
> list of outstanding merges, obfuscating the non-empty changes; right
> now you have to manually include them in your merge list.
This sounds cool although I am not sure how one would do this cheaply.
> Also, I created a little web page...
>
> http://www.dellroad.org/svnmerge/
>
> Thanks for the suggestions and for testing it out!
You bet. I'll *really* test it out when I have to do a merge for the
first time. :-)
Bruce.
Re: [PATCH] 'svnmerge' tool for automating merges
Posted by Archie Cobbs <ar...@dellroad.org>.
Bruce A. Mah wrote:
> > Attached is a tool called "svnmerge" that we're using locally to
> > automatically track merges from our trunk to branches. It stores the
> > merged-in revisions as a list in a property on the branch directory.
>
> One minor comment so far: You're pretty insistent in check_branch_dir()
> on having a totally clean WC before doing an init or merge operation.
> Seems to me you could be a teensy bit more forgiving without sacrificing
> correctness, I am thinking particularly of the case of unversioned files
> in the WC such as compiled object files. Maybe use the "-q" option in
> the second invocation of svn stat?
Yes, I did that because the merge will fail if a file that is added
in the merge also already exists (unversioned) in the branch tree.
The workaround is to put such files in svn:ignore. However, I agree
this is pretty conservative behavior, so maybe just letting the merge
fail and leaving it up to the user to fix is better.
On the other hand, having outstanding changes to versioned files (as
opposed to extra, unversioned files) is a much more serious threat to
the process.. because you could unwittingly "merge" in a change that
never existed in the head branch. That's much more important to guard
against.
Another thought I had is that it would be nice if it could auto-detect
any "empty" merges, i.e., commits that don't affect the head branch,
and go ahead and merge them in. Otherwise, they just clutter up the
list of outstanding merges, obfuscating the non-empty changes; right
now you have to manually include them in your merge list.
Also, I created a little web page...
http://www.dellroad.org/svnmerge/
Thanks for the suggestions and for testing it out!
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] 'svnmerge' tool for automating merges
Posted by "Bruce A. Mah" <bm...@acm.org>.
On Sun, 2004-09-26 at 16:18, Archie Cobbs wrote:
> Attached is a tool called "svnmerge" that we're using locally to
> automatically track merges from our trunk to branches. It stores the
> merged-in revisions as a list in a property on the branch directory.
>
> I know there are other developments in this area in the works, so
> this may be of limited value (and I haven't been following this
> mailing list so my information is out of date). In any case, it has
> proven useful here while more integrated merge tracking is being
> worked on.
Hey Archie--
This is pretty nice! I haven't played with it very much yet but I just
forked off a task branch for something I'm working on, so I'm going to
give svnmerge a try in managing merges from its parent.
One minor comment so far: You're pretty insistent in check_branch_dir()
on having a totally clean WC before doing an init or merge operation.
Seems to me you could be a teensy bit more forgiving without sacrificing
correctness, I am thinking particularly of the case of unversioned files
in the WC such as compiled object files. Maybe use the "-q" option in
the second invocation of svn stat?
Thanks for making this available!
Bruce.
PS. It sucks that we don't work in the same building anymore...in the
time it took me to write this up I could have walked over to your
office, told you in person, and maybe talked you into taking me on
another hundred dollar hamburger run. :-)