(Just looking back through my mail...)
Did this ever go anywhere? Is there still a problem that needs solving?
Freddie Albertsman wrote:
> Hey David!
> Yes, I have a patch for this, it should be applied to
> 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.
> 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?
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