You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Henrik Carlqvist <hc...@poolhem.se> on 2013/12/04 20:50:22 UTC
Re: svn log -g doesn't return merge info when operating against
repository root
On Wed, 25 Jul 2012 11:17:55 -0500
Justin Johnson <ju...@justinjohnson.io> wrote:
> The command "svn log -vg" is not returning merge info when I execute
> the command while sitting in a working copy of the root level of a
> repository or when I pass in the URL to the root level of root level
> on the command line. A simple test case can be seen below.
Sorry for my reply to a really old post, but it seems as if no one else
has replied and this problem also seems to still be there.
> echo "## Create repo ##"
> svnadmin create repo
>
> echo "## Add initial project ##"
> svn co file://`pwd`/repo wc
> cd wc
> mkdir -p p/trunk p/branches
> echo hi > p/trunk/file.txt
> svn add p
> svn ci -m "initial import"
>
> echo "## Copy trunk to A and make changes ##"
> svn cp p/trunk p/branches/A
> svn ci -m "Create branch A"
> echo hello >> p/branches/A/file.txt
> svn ci -m "Changes on A"
> svn up
>
> echo "## Merge A to trunk ##"
> cd p/trunk
> svn merge "^/p/branches/A"
> svn ci -m "Commit merge results"
> svn up
>
> echo "## Log from WC - trunk ##"
> svn log -vg
> cd ../..
>
> echo "## Log from WC - repo root ##"
> svn log -vg
> cd ..
>
> echo "## Log from URL - repo root ##"
> svn log -vg file://`pwd`/repo
However, this problem has not allways been like this, it seems as if this
bug came 2012. When I try an older version of svn it works as expected.
This is the output from 1.6.16:
-8<-------------------------------
minotaur:/tmp> svn --version
svn, version 1.6.16 (r1073529)
compiled Mar 9 2011, 19:14:47
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.apache.org/
This product includes software developed by CollabNet
(http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using
Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network
protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
minotaur:/tmp> echo "## Create repo ##"
## Create repo ##
minotaur:/tmp> svnadmin create repo
minotaur:/tmp>
minotaur:/tmp> echo "## Add initial project ##"
## Add initial project ##
minotaur:/tmp> svn co file://`pwd`/repo wc
Checked out revision 0.
minotaur:/tmp> cd wc
minotaur:/tmp/wc> mkdir -p p/trunk p/branches
minotaur:/tmp/wc> echo hi > p/trunk/file.txt
minotaur:/tmp/wc> svn add p
A p
A p/trunk
A p/trunk/file.txt
A p/branches
minotaur:/tmp/wc> svn ci -m "initial import"
Adding p
Adding p/branches
Adding p/trunk
Adding p/trunk/file.txt
Transmitting file data .
Committed revision 1.
minotaur:/tmp/wc>
minotaur:/tmp/wc> echo "## Copy trunk to A and make changes ##"
## Copy trunk to A and make changes ##
minotaur:/tmp/wc> svn cp p/trunk p/branches/A
A p/branches/A
minotaur:/tmp/wc> svn ci -m "Create branch A"
Adding p/branches/A
Committed revision 2.
minotaur:/tmp/wc> echo hello >> p/branches/A/file.txt
minotaur:/tmp/wc> svn ci -m "Changes on A"
Sending p/branches/A/file.txt
Transmitting file data .
Committed revision 3.
minotaur:/tmp/wc> svn up
At revision 3.
minotaur:/tmp/wc>
minotaur:/tmp/wc> echo "## Merge A to trunk ##"
## Merge A to trunk ##
minotaur:/tmp/wc> cd p/trunk
minotaur:/tmp/wc/p/trunk> svn merge "^/p/branches/A"
--- Merging r2 through r3 into '.':
U file.txt
minotaur:/tmp/wc/p/trunk> svn ci -m "Commit merge results"
Sending trunk
Sending trunk/file.txt
Transmitting file data .
Committed revision 4.
minotaur:/tmp/wc/p/trunk> svn up
At revision 4.
minotaur:/tmp/wc/p/trunk>
minotaur:/tmp/wc/p/trunk> echo "## Log from WC - trunk ##"
## Log from WC - trunk ##
minotaur:/tmp/wc/p/trunk> svn log -vg
------------------------------------------------------------------------
r4 | henca | 2013-12-04 19:46:17 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
M /p/trunk
M /p/trunk/file.txt
Commit merge results
------------------------------------------------------------------------
r3 | henca | 2013-12-04 19:46:14 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
M /p/branches/A/file.txt
Merged via: r4
Changes on A
------------------------------------------------------------------------
r2 | henca | 2013-12-04 19:46:13 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
A /p/branches/A (from /p/trunk:1)
Merged via: r4
Create branch A
------------------------------------------------------------------------
r1 | henca | 2013-12-04 19:46:11 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
A /p
A /p/branches
A /p/trunk
A /p/trunk/file.txt
initial import
------------------------------------------------------------------------
minotaur:/tmp/wc/p/trunk> cd ../..
minotaur:/tmp/wc>
minotaur:/tmp/wc> echo "## Log from WC - repo root ##"
## Log from WC - repo root ##
minotaur:/tmp/wc> svn log -vg
------------------------------------------------------------------------
r3 | henca | 2013-12-04 19:46:14 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
M /p/branches/A/file.txt
Changes on A
------------------------------------------------------------------------
r2 | henca | 2013-12-04 19:46:13 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
A /p/branches/A (from /p/trunk:1)
Create branch A
------------------------------------------------------------------------
r1 | henca | 2013-12-04 19:46:11 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
A /p
A /p/branches
A /p/trunk
A /p/trunk/file.txt
initial import
------------------------------------------------------------------------
minotaur:/tmp/wc> cd ..
minotaur:/tmp>
minotaur:/tmp> echo "## Log from URL - repo root ##"
## Log from URL - repo root ##
minotaur:/tmp> svn log -vg file://`pwd`/repo
------------------------------------------------------------------------
r4 | henca | 2013-12-04 19:46:17 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
M /p/trunk
M /p/trunk/file.txt
Commit merge results
------------------------------------------------------------------------
r3 | henca | 2013-12-04 19:46:14 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
M /p/branches/A/file.txt
Merged via: r4
Changes on A
------------------------------------------------------------------------
r2 | henca | 2013-12-04 19:46:13 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
A /p/branches/A (from /p/trunk:1)
Merged via: r4
Create branch A
------------------------------------------------------------------------
r3 | henca | 2013-12-04 19:46:14 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
M /p/branches/A/file.txt
Changes on A
------------------------------------------------------------------------
r2 | henca | 2013-12-04 19:46:13 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
A /p/branches/A (from /p/trunk:1)
Create branch A
------------------------------------------------------------------------
r1 | henca | 2013-12-04 19:46:11 +0100 (Wed, 04 Dec 2013) | 1 line
Changed paths:
A /p
A /p/branches
A /p/trunk
A /p/trunk/file.txt
initial import
------------------------------------------------------------------------
-8<-------------------------------
With my old version of svn the "Merged via: r4" are there both when
looking at trunk and the repository root. With newer versions of svn the
"Merged via: r4" are lost when looking at repository root.
regards Henrik
Re: svn2cvsgraph, how to best handle merges?
Posted by Henrik Carlqvist <hc...@poolhem.se>.
On Wed, 26 Mar 2014 19:41:38 +0000
Philip Martin <ph...@wandisco.com> wrote:
> Henrik Carlqvist <hc...@poolhem.se> writes:
> > Would people hosting public svn repositories think that it would be
> > nice if some people using my tool would make one svn connection for
> > each revision in the repository?
>
> It's a user problem as well since making a request per revision doesn't
> scale well and will be very slow for large projects.
As the merge information you get from "svn log -g" is somewhat recursive
it seems as if time grows exponentially with the number of revisions (or
maybe rather with the number of merges).
However, my own test version of svn2cvsgraph which calls svn once for each
revision does a pclose on the svn call after reading the first log entry
and the second log entry (which might be a merge). With such a solution
time grows linear with the number of revisions, but svn older than 1.7
will give some "svn: Write error: Broken pipe" to stderr.
I did a benchmark comparing a box running Slackware 14.1 with svn 1.7.16
and another box running Slackware 13.1 with svn 1.6.16. On these machines
I tested 3 version of svn2cvsgraph:
svn2cvsgraph 1.2: makes a single call to "svn log -q -g" on the subversion
repository root.
svn2cvsgraph 2.0: makes one call to "svn log -q -g" for each branch
(and trunk)
svn2cvsgraph 2.1beta: makes one call to "svn log -q -g" for each revision,
the call is aborted with pclose to avoid wasting
time on redundant information.
The benchmarks were run on a test subversion repository which was read
from a 2.9 GB big subversion dump file of an actual project repository.
The repository contains 13570 revisions and 160 branches. 206 merges has
been logged into the repository since the repository was upgraded to
version 1.5 of subversion. The test repository was accessed as file:/// on
an NFS server. Times were measured with the /usr/bin/time command.
These are the results:
subversion svn2cvsgraph time result
1.7.16 1.2 6:13.70elapsed 17%CPU No merges found
1.7.16 2.1beta 7:20.73elapsed 55%CPU All merges found
1.7.16 2.0 13:49.48elapsed 45%CPU 23 merges lost
1.6.16 2.1beta 52:53.63elapsed 81%CPU All merges found
1.6.16 1.2 134:55:22elapsed 41%CPU All merges found
1.6.16 2.0 135:14:04elapsed 41%CPU All merges found
Subversion 1.7.16 seems a lot faster than 1.6.16. Even though the tests
were run on different machines and the Slackware 14.1 machines is slightly
faster than the Slackware 13.1 machine I think that most of the difference
is thanks to that 1.7.16 gives less recursive merge information to wade
through.
No merges are found when only doing "svn log -q -g" on the repository root
with version 1.7.16. This is expected behavior as the behavior of "svn log
-g" changed with version 1.6.17.
23 merges were lost with "svn log -q -g" on every branch with 1.7.16, this
is most likely because of issue 4477.
Doing "svn log -q -g" for each revision and abort the output with pclose
is the fastest way to get correct results for both version 1.6.16 and
1.7.16. However, this is assuming that the repository is accessed with
file://. Previously I have instead been using svn+ssh:// with svn 1.6.16
and with one call for each branch or only for the repository root that
takes about 24 hours (compared with about 135 hours above). However using
svn+ssh:// instead of file:// when doing one call for each revision would
be a lot slower.
regards Henrik
Re: svn2cvsgraph, how to best handle merges?
Posted by Philip Martin <ph...@wandisco.com>.
Henrik Carlqvist <hc...@poolhem.se> writes:
> Would people hosting public svn repositories think that it would be nice
> if some people using my tool would make one svn connection for each
> revision in the repository?
It's a user problem as well since making a request per revision doesn't
scale well and will be very slow for large projects. The real solution
is to fix Subversion to efficiently return the information you need.
That's a topic for the dev list and there was some discussion last
month:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201402.mbox/%3C52FDD315.7030808@syntevo.com%3E
http://svn.haxx.se/dev/archive-2014-02/0140.shtml
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn2cvsgraph, how to best handle merges?
Posted by Henrik Carlqvist <hc...@poolhem.se>.
On Thu, 27 Mar 2014 11:25:33 +0100
"Bert Huijben" <be...@qqmail.nl> wrote:
> If you have any input on that thread, please let us know so we can just
> create the api you need to get the information you need.
My tool does not call use subversion api, it simply uses popen to call the
svn command line client.
So what I was hoping was to get some kind of "svn log -g -q" which only
displays all merge points once. Prefarably by only a single call to
svn, maybe by giving the subversion repository root as an argument, maybe
by giving some extra flag asking svn to omit recursive merges.
However, if it would be easier to give this kind of functionality by the
API than by the command line tool I could rewrite my tool to use the API.
> Of course we can't add it to old Subversion server versions, but we
> surely can add new apis...
I understand that. Once we get a working combo I will simply have to
document a requirement that at least version v.x of subversion is needed
to work togehter with version w.z of svn2cvsgraph.
> But we need usecases to create apis... and preferably testcases.
>
> If there is some very rough prototype that you can share... perhaps with
> pointers on how it can and should be improved we can work together on
> adding the apis that you need.
Looking at the test case posted at
http://svn.haxx.se/users/archive-2014-02/0219.shtml
I think that the most effective output for my program to parse would be
something like:
------------------------------------------------------------------------
r12 | henca | 2014-02-25 13:06:18 +0100 (Tue, 25 Feb 2014)
------------------------------------------------------------------------
r11 | henca | 2014-02-25 13:06:17 +0100 (Tue, 25 Feb 2014)
Merged via: r12
------------------------------------------------------------------------
r10 | henca | 2014-02-25 13:06:16 +0100 (Tue, 25 Feb 2014)
Merged via: r11
------------------------------------------------------------------------
r9 | henca | 2014-02-25 13:06:15 +0100 (Tue, 25 Feb 2014)
Merged via: r10
------------------------------------------------------------------------
r8 | henca | 2014-02-25 13:06:14 +0100 (Tue, 25 Feb 2014)
------------------------------------------------------------------------
r5 | henca | 2014-02-25 13:06:12 +0100 (Tue, 25 Feb 2014)
Merged via: r8
------------------------------------------------------------------------
r7 | henca | 2014-02-25 13:06:13 +0100 (Tue, 25 Feb 2014)
------------------------------------------------------------------------
r6 | henca | 2014-02-25 13:06:13 +0100 (Tue, 25 Feb 2014)
------------------------------------------------------------------------
r5 | henca | 2014-02-25 13:06:12 +0100 (Tue, 25 Feb 2014)
------------------------------------------------------------------------
r4 | henca | 2014-02-25 13:06:12 +0100 (Tue, 25 Feb 2014)
------------------------------------------------------------------------
r3 | henca | 2014-02-25 13:06:12 +0100 (Tue, 25 Feb 2014)
------------------------------------------------------------------------
r2 | henca | 2014-02-25 13:06:11 +0100 (Tue, 25 Feb 2014)
------------------------------------------------------------------------
r1 | henca | 2014-02-25 13:06:11 +0100 (Tue, 25 Feb 2014)
------------------------------------------------------------------------
In the example output above, there is exactly one "Merged via:" for each
commited "svn merge".
I am fully aware that reading the log above by hand after following the
svn commands at http://svn.haxx.se/users/archive-2014-02/0219.shtml is a
little bit hard to follow. Looking at a .png file with merge arrows makes
it a lot easier to follow. I have placed such a file at
http://poolhem.se/bilder/revision_graph.png
Output like the one above would probably be the easiest for my program to
parse, but if I get some kind of api I could also use that.
regards Henrik
RE: svn2cvsgraph, how to best handle merges?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Henrik Carlqvist [mailto:hc528@poolhem.se]
> Sent: donderdag 27 maart 2014 07:47
> To: Mark Phippard; philip.martin@wandisco.com;
> users@subversion.apache.org
> Subject: Re: svn2cvsgraph, how to best handle merges?
>
> On Wed, 26 Mar 2014 15:45:31 -0400
> Mark Phippard <ma...@gmail.com> wrote:
> > We came to the same conclusion when we built the revision graph in
> > Subclipse back in 1.5:
> >
> > http://subclipse.tigris.org/graph.html
>
> On Wed, 26 Mar 2014 19:41:38 +0000
> Philip Martin <ph...@wandisco.com> wrote:
> That's a topic for the dev list and there was some discussion last
> > month:
> >
> > http://mail-archives.apache.org/mod_mbox/subversion-
> dev/201402.mbox/%3C52FDD315.7030808@syntevo.com%3E
> > http://svn.haxx.se/dev/archive-2014-02/0140.shtml
>
> Thanks for the information that others writing simular tools have seen the
> same problem, I wasn't aware of the discussion on the dev list as I don't
> subscribe to it. Right now I will not do any release of svn2cvsgraph which
> querys every revision, instead I will wait and hope for the best.
If you have any input on that thread, please let us know so we can just
create the api you need to get the information you need.
Of course we can't add it to old Subversion server versions, but we surely
can add new apis...
But we need usecases to create apis... and preferably testcases.
If there is some very rough prototype that you can share... perhaps with
pointers on how it can and should be improved we can work together on adding
the apis that you need.
And with some things running on the server side things might be much faster
in Subversion 1.9, 1.10 or .....
Bert
Re: svn2cvsgraph, how to best handle merges?
Posted by Henrik Carlqvist <hc...@poolhem.se>.
On Wed, 26 Mar 2014 15:45:31 -0400
Mark Phippard <ma...@gmail.com> wrote:
> We came to the same conclusion when we built the revision graph in
> Subclipse back in 1.5:
>
> http://subclipse.tigris.org/graph.html
On Wed, 26 Mar 2014 19:41:38 +0000
Philip Martin <ph...@wandisco.com> wrote:
That's a topic for the dev list and there was some discussion last
> month:
>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201402.mbox/%3C52FDD315.7030808@syntevo.com%3E
> http://svn.haxx.se/dev/archive-2014-02/0140.shtml
Thanks for the information that others writing simular tools have seen the
same problem, I wasn't aware of the discussion on the dev list as I don't
subscribe to it. Right now I will not do any release of svn2cvsgraph which
querys every revision, instead I will wait and hope for the best.
My guess is that SmartSVN and subclipse also find much of the output from
"svn log -g" rather redundant. This kind of tools usually only displays
merge points, not considering if those merges are more or less complete. I
can understand if other users need some kind of tool to display what
merges really contain, but for this kind of graphs only the merge points
without the recursive previous merges are interesting.
If it would help to write some kind of merge log functionality that does
not display recursive older merges that kind of log would probably useful
for our tools. However, it is better to have too much information in the
logs than to have missing information.
regards Henrik
Re: svn2cvsgraph, how to best handle merges?
Posted by Mark Phippard <ma...@gmail.com>.
We came to the same conclusion when we built the revision graph in
Subclipse back in 1.5:
http://subclipse.tigris.org/graph.html
Trying to do log on a whole branch with -g could even get quadratic loops
and take forever. Doing it one revision at a time was the only thing that
would work but then it does not perform. At the time, something I had
asked for was a way to get run log on a branch and get a boolean for every
revision where mergeinfo changed so that we could then just follow up and
ask for those revisions.
A better solution as Philip suggests would be even better.
Mark
On Wed, Mar 26, 2014 at 3:15 PM, Henrik Carlqvist <hc...@poolhem.se> wrote:
> I have written a tool, svn2cvsgraph
> ( http://svn2cvsgraph.sourceforge.net/ )
> to graphically display svn revision graphs.
>
> Since version 1.6.17 of svn, "svn log -g" no longer shows any merges when
> examining the repository root. After a discussion, here
> http://svn.haxx.se/users/archive-2013-12/0029.shtml
> I rewrote svn2cvsgraph to not only do "svn log -g" on the repository root,
> but for trunk and every branch in the repository.
>
> After releasing that new version of svn2cvsgraph I found that some merge
> information is missing from svn versions newer than 1.6.17 even when
> examining each branch. I filed an issue about this (issue 4477).
>
> I could once again rewrite svn2cvsgraph to also work with newer versions
> of svn. The solution would be to make one call to "svn log -g" not only
> for each branch but for every revision. I have done some internal testing
> with this approach and the C code for svn2cvsgraph looks nice and clean,
> but I still hesitate to make such a version of svn2cvsgraph public.
>
> Would people hosting public svn repositories think that it would be nice
> if some people using my tool would make one svn connection for each
> revision in the repository?
>
> regards Henrik
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
svn2cvsgraph, how to best handle merges?
Posted by Henrik Carlqvist <hc...@poolhem.se>.
I have written a tool, svn2cvsgraph
( http://svn2cvsgraph.sourceforge.net/ )
to graphically display svn revision graphs.
Since version 1.6.17 of svn, "svn log -g" no longer shows any merges when
examining the repository root. After a discussion, here
http://svn.haxx.se/users/archive-2013-12/0029.shtml
I rewrote svn2cvsgraph to not only do "svn log -g" on the repository root,
but for trunk and every branch in the repository.
After releasing that new version of svn2cvsgraph I found that some merge
information is missing from svn versions newer than 1.6.17 even when
examining each branch. I filed an issue about this (issue 4477).
I could once again rewrite svn2cvsgraph to also work with newer versions
of svn. The solution would be to make one call to "svn log -g" not only
for each branch but for every revision. I have done some internal testing
with this approach and the C code for svn2cvsgraph looks nice and clean,
but I still hesitate to make such a version of svn2cvsgraph public.
Would people hosting public svn repositories think that it would be nice
if some people using my tool would make one svn connection for each
revision in the repository?
regards Henrik
Re: svn log -g doesn't return merge info when operating against
repository root
Posted by Henrik Carlqvist <hc...@poolhem.se>.
Thanks for your quick reply!
> Log on ^/ shows all revisions; adding -g includes no more revisions.
Yep, that is the problem. IMHO the flag -g should also give output which
shows merge information, not only on deeper levels but also on the root
level of the repository. I can understand if most people don't want the
extra merge information, but if you don't want it you simply call svn
without the flag -g.
I don't know why Justin needs the feature of -g on the repository root,
but I can tell how I use it:
I have written a utility which does call "svn log -q -g file://`pwd`/repo"
and uses the information it gets from that to draw revision tree graphs.
My utility is at http://svn2cvsgraph.sourceforge.net/ , using that utility
together with svn versions newer than about two years will give no merge
arrows in the produced graphs. It would probably be possible to rewrite my
utility to get all merge information also from newer versions of svn, but
it would be slower as it would require at least one extra call to svn for
each created branch.
regards Henrik
Re: svn log -g doesn't return merge info when operating against repository root
Posted by Philip Martin <ph...@wandisco.com>.
Henrik Carlqvist <hc...@poolhem.se> writes:
> On Wed, 25 Jul 2012 11:17:55 -0500
> Justin Johnson <ju...@justinjohnson.io> wrote:
>
>> The command "svn log -vg" is not returning merge info when I execute
>> the command while sitting in a working copy of the root level of a
>> repository or when I pass in the URL to the root level of root level
>> on the command line. A simple test case can be seen below.
>
> Sorry for my reply to a really old post, but it seems as if no one else
> has replied and this problem also seems to still be there.
There is a behaviour change but I believe it is deliberate. Running log
without -g shows a certain set of revision. Adding -g causes log to
show more revision and those extra revision, and only those extra
revisions, are marked "Merged via". The "Merged via" marking indicates
that these revisions are not part of the direct history.
svnadmin create repo --compatible-version 1.6
svn mkdir -mm --parents file://`pwd`/repo/P/A # r1
svn cp -mm file://`pwd`/repo/P/A ^/P/B # r2
svn cp -mm file://`pwd`/repo/P/B ^/C # r3
svn mkdir -mm file://`pwd`/repo/C/X # r4
svn co file://`pwd`/repo wc
svn merge ^/C wc/P/B
svn ci -mm wc # r5
svn merge ^/P/B wc/P/A
svn ci -mm wc # r6
Log on ^/P/A shows revisions 6 and 1; adding -g includes the extra
revisions 2, 3, 4 and 5 marked "Merged via".
Log on ^/P shows revisions 6, 5, 2 and 1; adding -g includes 3 and 4
marked "Merged via".
Log on ^/ shows all revisions; adding -g includes no more revisions.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*