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

Re: [PATCH] Copy/move-handling on update in 1.5

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 28 Jan 2008 22:08:34 +0000

(Just looking back through my mail...)

Freddie/David/anyone,

Did this ever go anywhere? Is there still a problem that needs solving?

- Julian

Freddie Albertsman wrote:
>
> Hey David!
>
> Yes, I have a patch for this, it should be applied to
> ../libsvn_repos/reporter.c.
>
> There is a function (check_order) that checks if the entry is "special",
> which means if it is be merged with a newer version with a different
> names. In which case it will be deleted at the end. It works on linux
> but i haven't tested in windows, but it should work there too. Sorry i
> didn't send this before i was sick+busy.
>
> Yours,
> Freddie
>
>
> On Dec 10, 2007 7:26 PM, David Glasser < glasser_at_davidglasser.net
> <mailto:glasser_at_davidglasser.net>> wrote:
>
> On Dec 6, 2007 2:10 AM, Freddie Albertsman <c03fan_at_cs.umu.se
> <mailto:c03fan_at_cs.umu.se>> wrote:
> > Hey Guys!
> > I have one question concerning concerning the "update ignores added
> > files/dirs":
> >
> > Consider the following scenario:
> >
> > repos. contains /trunk/foo
> >
> > #user A
> > rename foo -> bar
> > echo "HELLO BAR" > bar
> >
> > #user B
> > rename foo -> baz
> > echo "HELLO BAZ" > baz
> > commit
> >
> > #user A
> > update
> >
> > Now if the "newly" added file, bar, in user A's wc is ignored
> then the
> > server will throw a new file (baz coming from B). When user A
> commits after
> > updating, the file "bar" will be added as well and we end up with
> two files
> > in the repository where it should have been only one file. I
> think that
> > files which are added AND copied should not be ignored.
> > What do you think guys?
>
> This point is interesting, but I don't think it's related to the new
> 1.5 feature; the behavior you point out occurs in 1.4 as well.
>
> > One more thing, I think I might have solved an issue about copying on
> > updating described in this scenario:
> > 1.User A checks out /repos/trunk/proj containing foo.c
> > 2.User B checks out /repos/trunk/proj containing foo.c
> > 3.User A makes changes to foo.c
> > 4.User B renames foo.c to bar.c and makes some changes
> > 5.User B commits
> > 6.User A updates
> >
> > Ben said that this scenario would if the deletetion of foo
> happens AFTER
> > the add of bar (when A does an update). Well, now it the deletion
> of foo
> > happens after the addition of bar if bar has a copyfrom that is
> (foo). So
> > when at step 6, A does an update, then the bar is merged with foo
> and then
> > bar is added and foo deleted.
>
> I can't follow if you're saying that you have a patch that
> implements this?
>
> --dave

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-28 23:08:51 CET

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

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