[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Fwd: Re: "svn log -v" : What is 'R' action?

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-10-03 22:49:33 CEST

Forwarding to the list what should have been sent there...

---------- Forwarded message ----------
From: Erik Huelsmann <ehuels@gmail.com>
Date: Oct 3, 2007 10:48 PM
Subject: Re: Re: "svn log -v" : What is 'R' action?
To: Jonathan Ashley <jonathan.ashley@praxis-his.com>

On 10/3/07, Jonathan Ashley <jonathan.ashley@praxis-his.com> wrote:
> I don't think you are overlooking anything. I was baffled by unexpected
> Replacements and eventually tracked it down to the same thing: if a
> directory
> is added on a branch and the branch then merged back on to the trunk,
> the
> new directory appears on the trunk flagged as 'A', but the contents are
> flagged as 'R'.
>
> I found your post when looking to see if anyone had reported a similar
> problem. I would guess there's a good reason for the behaviour -
> probably
> reflects the way it is implemented internally - but it is certainly
> confusing
> (and undocumented).

It's certainly an exponent of how it's implemented, but certainly not
how it should have been implemented. However, given how merge (and the
resulting commit) are -currently- implemented, it's reported as 'R'
instead of 'A'. I hope to fix this some time before 1.6, but that's
some time away, since 1.5 is still to be released...

bye,

Erik.

> Regards,
> --
> Jon Ashley
>
> > -----Original Message-----
> > From: Mark Reibert [mailto:svn@reibert.com]
> > Sent: 14 September 2007 05:14
> > To: Hari Kodungallur
> > Cc: users@subversion.tigris.org
> > Subject: Re: "svn log -v" : What is 'R' action?
> >
> > On Thu, 2007-09-13 at 10:03 -0700, Hari Kodungallur wrote:
> > >
> > > On 9/12/07, Mark Reibert <svn@reibert.com> wrote:
> > > Now "svn log -v" shows the top-level directory of
> > the merge as
> > > 'A', but
> > > everything else - directories and files - have an action of
> > > 'R'. Here is
> > > a sanitized piece of the output:
> > >
> > > Changed paths:
> > > A /branches/B/foo (from /branches/A/foo:1407)
> > > R /branches/B/foo/bar (from /branches/A/foo/bar:1407)
> > >
> > > and so on. The only discussion I can find in the turtle book
> > > is in the
> > > context of "svn up", where 'R' means "replaced".
> > This does not
> >
> > Oops, I meant "svn st" ...
> >
> > > The 'R' flag represent the same meaning for log, status,
> > update, merge
> > > etc. It means replaced. If my understanding is right,
> > replaced means
> > > that you deleted and added a file in the same revision.
> > That is, you
> > > do a "svn rm" of the file (don't commit it) and then "svn
> > add" a file
> > > with the same name. Then do the commit. At this point you will see
> > > that the commit happens as "R". And hence the log will also
> > show this
> > > revision as an "R".
> >
> > Presumably yes, but this is the part that does not make
> > sense. For my case, the merge simply added *new*
> > directories/files to the target branch (via the working
> > copy). As I noted, "svn st" on the working copy after the
> > merge shows everything as "A +", which I expect. What I
> > don't understand is why after committing "A +" I get 'R'
> > from "svn log". And why does the top-level new directory show
> > 'A' while all its children show 'R'?
> >
> > I have to believe I am overlooking something very fundamental here ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 3 22:50:07 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.