resolve conflict dialog is confusing
spongman
two buttons:
- Use local
- Use repository
the wording of these buttons is ambguous and confusing.
the term 'repository' is ambiguous since both branches are in the
repository, and this button does not disambiguate between them.
the term 'local' sin't much better - does it refer to my working copy
before the merge, the working copy after the failed merge, some other
local copy?
also, can we get accelerators for these (all!) buttons?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2648910
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
Dave Huang
> the term 'repository' is ambiguous since both branches are in the
> repository, and this button does not disambiguate between them.
>
> the term 'local' sin't much better - does it refer to my working copy
> before the merge, the working copy after the failed merge, some other
> local copy?
between a working copy and the repository. When you do a merge, you
generally only specify a single repository URL (the exception being the
"merge two different trees" option, but in that case, both repo URLs
define the "source" of the merge; you're still merging into your working
copy).
In any case, I don't think the documentation for the conflict resolution
process needs to be on the window; the terms are clear enough if you
read the TSVN help file.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2648911
Tom von Alten
> the term 'repository' is ambiguous since both branches are in the
> repository, and this button does not disambiguate between them.
> the term 'local' sin't much better - does it refer to my working copy
> before the merge, the working copy after the failed merge, some other
> local copy?
I just stumbled into exactly the same questions about the meaning of
the terms in this dialog.
Dave Huang replied:
> Merges aren't done on branches in the repository though--they're done
> between a working copy and the repository. When you do a merge, you
> generally only specify a single repository URL...
I take that as an answer for the "Merge a range of revisions"
interface,
"Repository" means the one and only one Repository I pointed to
explicitly,
just ignore the fact that my action is on a working copy of something
that
points to a different repository.
> (the exception being the "merge two different trees" option, but in that
> case, both repo URLs define the "source" of the merge; you're still merging
> into your working copy).
In the case of conflicts between those 2 source URLs, how does a
single
button labeled "Use Repository" specify how to resolve a conflict?
> In any case, I don't think the documentation for the conflict resolution
> process needs to be on the window; the terms are clear enough if you
> read the TSVN help file.
Searching for "tortoisesvn resolve conflict dialog" led me to the help
file
page titled "Resolving conflicts", in which "Use local" and "Use
repository"
are not mentioned, nor the conflict dialog illustrated. Oddly.
At the bottom of the "Merging" help file, there's a section "Handling
Conflicts during Merge" which does show the conflict dialog and its
buttons,
and suggests the answer I've inferred, but does not come right out and
say
WHICH REPOSITORY, even though the "Merging" page covers the whole
gamut of
methods.
I agree with spongman. If the dialog could provide a simple
disambiguation,
it would be good. And further, I think the documentation should be
enhanced
with "See also" hyperlinks, at least.
Take my observation for what it's worth, as someone quite new (and
struggling for several days now) with the business of merging with
TortoiseSVN.
There's no review resource like the innocent newcomer, eh?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654199
David Huang
> Dave Huang replied:
>> Merges aren't done on branches in the repository though--they're done
>> between a working copy and the repository. When you do a merge, you
>> generally only specify a single repository URL...
>
> I take that as an answer for the "Merge a range of revisions"
> interface,
> "Repository" means the one and only one Repository I pointed to
> explicitly,
> just ignore the fact that my action is on a working copy of something
> that
> points to a different repository.
I'm not sure what you mean by "my action is on a working copy of something that points to a different repository." You can't merge between two repositories. The merge source is the repository, the merge destination is your local working copy, which was created from that same repository.
> In the case of conflicts between those 2 source URLs, how does a
> single
> button labeled "Use Repository" specify how to resolve a conflict?
Not sure what you mean by "conflicts between those 2 source URLs". It doesn't make sense to talk about a conflict there. Maybe you're confused about the merge process in general? In which case, perhaps the Subversion manual (rather than the TortoiseSVN manual) would be a good place to start: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html
Merging can be though of taking a diff between two revisions of the repository as the "source" and applying that diff as a patch to your working copy. For a simple merge that you only need to specify one repository URL for, SVN takes a diff between rev X of that URL and rev Y of that URL and applies it to your working copy. For the merge that takes two repository URLs, SVN takes a diff between rev X of URL 1 and rev Y of URL2 and applies *that* to your working copy. But the two URLs are just used to generate a diff, so there's nothing that can conflict at that point.
> At the bottom of the "Merging" help file, there's a section "Handling
> Conflicts during Merge" which does show the conflict dialog and its
> buttons,
> and suggests the answer I've inferred, but does not come right out and
> say
> WHICH REPOSITORY, even though the "Merging" page covers the whole
> gamut of
> methods.
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html#tsvn-dug-merge-conflict-callback is what I was referring to, and it sounds like that's what you're talking about too. There is no "which repository"--there's only one repository.
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 34 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654213
Bob Archer
> > Dave Huang replied:
> >> Merges aren't done on branches in the repository though--they're
> done
> >> between a working copy and the repository. When you do a merge,
> you
> >> generally only specify a single repository URL...
> >
> > I take that as an answer for the "Merge a range of revisions"
> > interface,
> > "Repository" means the one and only one Repository I pointed to
> > explicitly,
> > just ignore the fact that my action is on a working copy of
> something
> > that
> > points to a different repository.
>
> I'm not sure what you mean by "my action is on a working copy of
> something that points to a different repository." You can't merge
> between two repositories. The merge source is the repository, the
> merge destination is your local working copy, which was created
> from that same repository.
I'm not sure that is really 100% correct. My understanding of a merge is that a diff is taken of two locations and that diff is applied to your current working copy. From the red-bean svn book:
---
"The main source of confusion is the name of the command. The term "merge" somehow denotes that branches are combined together, or that some sort of mysterious blending of data is going on. That's not the case. A better name for the command might have been svn diff-and-apply, because that's all that happens: two repository trees are compared, and the differences are applied to a working copy."
---
So, you can merge the diffs between the paths of two different repositories. I don't recall when it was added that you can diff separate repos... but I think it has been doable since some time after 1.5.
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654275
David Huang
> So, you can merge the diffs between the paths of two different repositories. I don't recall when it was added that you can diff separate repos... but I think it has been doable since some time after 1.5.
Hmm, it doesn't work for me in the commandline svn:
% svn --version
svn, version 1.6.5 (r38866)
[ ... ]
% svn diff http://tortoisesvn.googlecode.com/svn/trunk/build.txt http://svn.apache.org/repos/asf/subversion/trunk/README
svn: 'http://tortoisesvn.googlecode.com/svn/trunk/build.txt' isn't in the same repository as 'http://svn.apache.org/repos/asf'
But you're right that with TSVN, I can "Diff with URL" a file in my working copy from one repository against a file in another repository. I don't actually know how to diff two URLs with TSVN (without needing a working copy at all)... there doesn't seem to be a "Diff with URL" option in the TSVN Repo browser.
That said, a Tree merge with the "From" and "To" from separate repositories doesn't work in TSVN either; you get the same
Error: 'http://tortoisesvn.googlecode.com/svn/trunk' isn't in the same repository as 'http://svn.apache.org/repos/asf/subversion/trunk'
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 34 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654283
Bob Archer
> > So, you can merge the diffs between the paths of two different
> repositories. I don't recall when it was added that you can diff
> separate repos... but I think it has been doable since some time
> after 1.5.
>
>
> Hmm, it doesn't work for me in the commandline svn:
>
> % svn --version
> svn, version 1.6.5 (r38866)
> [ ... ]
> % svn diff http://tortoisesvn.googlecode.com/svn/trunk/build.txt
> http://svn.apache.org/repos/asf/subversion/trunk/README
> svn: 'http://tortoisesvn.googlecode.com/svn/trunk/build.txt' isn't
> in the same repository as 'http://svn.apache.org/repos/asf'
>
> But you're right that with TSVN, I can "Diff with URL" a file in my
> working copy from one repository against a file in another
> repository. I don't actually know how to diff two URLs with TSVN
> (without needing a working copy at all)... there doesn't seem to be
> a "Diff with URL" option in the TSVN Repo browser.
>
> That said, a Tree merge with the "From" and "To" from separate
> repositories doesn't work in TSVN either; you get the same
>
> Error: 'http://tortoisesvn.googlecode.com/svn/trunk' isn't in the
> same repository as
> 'http://svn.apache.org/repos/asf/subversion/trunk'
Try the merge command. I guess diff doesn't support it.
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654285
David Huang
> Try the merge command. I guess diff doesn't support it.
I did try a merge; the last error in my previous message was from TSVN 1.6.10, Merge two different trees, From: http://tortoisesvn.googlecode.com/svn/trunk/ HEAD revision, To: http://svn.apache.org/repos/asf/subversion/trunk HEAD revision. A Test merge gives the error:
Error: 'http://tortoisesvn.googlecode.com/svn/trunk' isn't in the same repository as 'http://svn.apache.org/repos/asf/subversion/trunk'
If you meant commandline svn, same thing:
% svn merge --dry-run http://tortoisesvn.googlecode.com/svn/trunk http://svn.apache.org/repos/asf/subversion/trunk
svn: 'http://tortoisesvn.googlecode.com/svn/trunk' isn't in the same repository as 'http://svn.apache.org/repos/asf/subversion/trunk'
But in any case, the point remains that even if you could diff between two repositories, there's not going to be any conflict at the point of the diff. The conflicts occur when the diff is applied to your local working copy, so the choices for resolving the conflict is to use the changes from the repository diff, use the changes from the local working copy, or manually pick and choose. "Use repository" is unambiguous.
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 34 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654315
Tom von Alten
> I'm not sure what you mean by "my action is on a working copy of
> something that points to a different repository." You can't merge
> between two repositories. The merge source is the repository, the
> merge destination is your local working copy, which was created
> from that same repository.
Sorry I don't have the terminology in hand, reading your response
suggests I meant "two revisions in the repository." I'm merging
changes contained in a branch to a working copy of the trunk.
The ambiguity is which of two versions in the repository that "use
repository" refers to. For a mod of a working copy of the trunk,
using changes contained in a branch in the repository, it (now, thank
you) seems clear enough that Tortoise refers to the branch version in
the repository.
> Not sure what you mean by "conflicts between those 2 source URLs".
If you're merging two trees, there are two source URLs, and two
versions in the repository at issue. Does it offer the choice to "Use
repository" for that, and if so, which one does it refer to?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654312
David Huang
> The ambiguity is which of two versions in the repository that "use
> repository" refers to. For a mod of a working copy of the trunk,
> using changes contained in a branch in the repository, it (now, thank
> you) seems clear enough that Tortoise refers to the branch version in
> the repository.
You're merging the *changes* between two revisions, not merging the two revisions themselves. "Use repository" means to go ahead and take those changes, even if they conflict with changes you have in your local working copy. And conversely, "Use local" means to use the changes you made in your local working copy, rather than the changes from the repository.
> If you're merging two trees, there are two source URLs, and two
> versions in the repository at issue. Does it offer the choice to "Use
> repository" for that, and if so, which one does it refer to?
Right, there are two source URLs, but they're both in the same repository. As I mentioned earlier (and tested empirically), Subversion requires that both URLs be in the same repo. So just like the case mentioned earlier, you're merging the changes between two revisions in the one repository. "Use repository" is unambiguous--there aren't two repositories to choose from. There's just the one repository, and the one working copy.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654324
Tom von Alten
> You're merging the *changes* between two revisions, not merging
> the two revisions themselves.
< blink! > Light bulb goes on.
But I still feel a little shaky. I'll work with it a while and see how
I do.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654329
Stefan Wild
reading the last discussion about conflict merges reminded me of a "problem" I always have when I make an svn update on my working copy.
If there was something changed and committed by anyone else and I changed something in the same file, this usually results in a (non-conflict) merge and the filename is shown in green.
But now the problem:
how can I find out which changes in that file were made by me and which changes came from the newer revision I just got? I can double-click on this file or right-click -> "Compare with working copy" (which is bold, so it'd be to expect the default double-click action), and both of those shows me some kind of diff, but it's neither the same like the other one nor the diff I would expect.
What I *would* expect was:
= for changes that were made in both revisions
+ on the left side for changes commited by someone else
+ on the right side for changes that I made in my wc
now I'm unsure if *I* do something wrong or tsvn does...
any suggestions?
--
Mit freundlichen Grüßen
Stefan Wild
autinity systems GmbH
Neefestraße 42
D-09119 Chemnitz
Amtsgericht Chemnitz HRB: 21552
Telefon: +49 (0) 371 918897-50
Fax: +49 (0) 371 918897-49
email: stefa...@autinity.de
web: www.autinity.de
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654470
Bob Archer
> "problem" I always have when I make an svn update on my working
> copy.
> If there was something changed and committed by anyone else and I
> changed something in the same file, this usually results in a (non-
> conflict) merge and the filename is shown in green.
> But now the problem:
> how can I find out which changes in that file were made by me and
> which changes came from the newer revision I just got? I can
> double-click on this file or right-click -> "Compare with working
> copy" (which is bold, so it'd be to expect the default double-click
> action), and both of those shows me some kind of diff, but it's
> neither the same like the other one nor the diff I would expect.
> What I *would* expect was:
> = for changes that were made in both revisions
> + on the left side for changes commited by someone else
> + on the right side for changes that I made in my wc
>
> now I'm unsure if *I* do something wrong or tsvn does...
> any suggestions?
>
I don't think anything is wrong. When you do an "Update" and changes to a dirty file are merged into your working copy there is really no easy way to see the diffs. What you should do if you commit and it fails due to out of date WC file then do a Diff with URL at that point. This will show you the diff between what you have and what is in the repository.
You could try a BLAME but I'm not sure what that will show on a working copy.
You can also do a diff in the repository (log viewer) of the HEAD and the previous revision to see what changes that were made and merged into your source.
Of course, if you just DIFF your file would you not remember what changes YOU made and what changes are there that you didn't make?
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654802
Bob Archer
> TSVN 1.6.10, Merge two different trees, From:
> http://tortoisesvn.googlecode.com/svn/trunk/ HEAD revision, To:
> http://svn.apache.org/repos/asf/subversion/trunk HEAD revision. A
> Test merge gives the error:
>
> Error: 'http://tortoisesvn.googlecode.com/svn/trunk' isn't in the
> same repository as
> 'http://svn.apache.org/repos/asf/subversion/trunk'
>
> If you meant commandline svn, same thing:
>
> % svn merge --dry-run http://tortoisesvn.googlecode.com/svn/trunk
> http://svn.apache.org/repos/asf/subversion/trunk
> svn: 'http://tortoisesvn.googlecode.com/svn/trunk' isn't in the
> same repository as
> 'http://svn.apache.org/repos/asf/subversion/trunk'
Yes, you are correct. I was thinking that "merge from foreign repositories" allowed for comparing paths in two seperate repos. But, alas that's not supported as you found out. Sorry about that rabbit hole.
http://blogs.open.collab.net/svn/2008/03/do-not-post-mer.html
> But in any case, the point remains that even if you could diff
> between two repositories, there's not going to be any conflict at
> the point of the diff. The conflicts occur when the diff is applied
> to your local working copy, so the choices for resolving the
> conflict is to use the changes from the repository diff, use the
> changes from the local working copy, or manually pick and choose.
> "Use repository" is unambiguous.
That I 100% agree with.
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654813
Bob Archer
> > I'm not sure what you mean by "my action is on a working copy of
> > something that points to a different repository." You can't merge
> > between two repositories. The merge source is the repository, the
> > merge destination is your local working copy, which was created
> > from that same repository.
>
> Sorry I don't have the terminology in hand, reading your response
> suggests I meant "two revisions in the repository." I'm merging
> changes contained in a branch to a working copy of the trunk.
>
> The ambiguity is which of two versions in the repository that "use
> repository" refers to. For a mod of a working copy of the trunk,
> using changes contained in a branch in the repository, it (now,
> thank
> you) seems clear enough that Tortoise refers to the branch version
> in
> the repository.
>
> > Not sure what you mean by "conflicts between those 2 source
> URLs".
>
> If you're merging two trees, there are two source URLs, and two
> versions in the repository at issue. Does it offer the choice to
> "Use
> repository" for that, and if so, which one does it refer to?
When you do a merge svn does a DIFF between the two URLs that you specify (or that merge track determines to be correct). If that diff... lets say LINE 125 was edited is applied to a local file in which YOU also edit LINE 125 there would be an conflit. So, you can choose "Take LINE 125 as it is in my working copy" (Use Local) or "Take LINE 125 that comes from the DIFF that occured against the two repo versions" (Use Repository).
Your best bet of course is to "Edit Conflict" with a 3-way merge tool like Torsoise Merge or Beyond Compare 3 so you can see the change in the LOCAL (yours), the Change in the REPOSITORY (thiers), the common base, The final result of the merge. I would never blindly take LOCAL or REPO unless it was a binary and I have no choice but to choose 1 or the other... or I KNOW for sure I just made a conflicting change and I want to use "mine" for it.
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2654861
Stefan Wild
>> "problem" I always have when I make an svn update on my working
>> copy.
>> If there was something changed and committed by anyone else and I
>> changed something in the same file, this usually results in a (non-
>> conflict) merge and the filename is shown in green.
>> But now the problem:
>> how can I find out which changes in that file were made by me and
>> which changes came from the newer revision I just got? I can
>> double-click on this file or right-click -> "Compare with working
>> copy" (which is bold, so it'd be to expect the default double-click
>> action), and both of those shows me some kind of diff, but it's
>> neither the same like the other one nor the diff I would expect.
>> What I *would* expect was:
>> = for changes that were made in both revisions
>> + on the left side for changes commited by someone else
>> + on the right side for changes that I made in my wc
>>
>> now I'm unsure if *I* do something wrong or tsvn does...
>> any suggestions?
> I don't think anything is wrong. When you do an "Update" and changes to a dirty file are merged into your working copy there is really no easy way to see the diffs.
> What you should do if you commit and it fails due to out of date WC file then do a Diff with URL at that point. This will show you the diff between what you have and what is in the repository.
> You could try a BLAME but I'm not sure what that will show on a working copy.
> You can also do a diff in the repository (log viewer) of the HEAD and the previous revision to see what changes that were made and merged into your source.
> Of course, if you just DIFF your file would you not remember what changes YOU made and what changes are there that you didn't make
--
Mit freundlichen Grüßen
Stefan Wild
autinity systems GmbH
Neefestraße 42
D-09119 Chemnitz
Amtsgericht Chemnitz HRB: 21552
Telefon: +49 (0) 371 918897-50
Fax: +49 (0) 371 918897-49
email: stefa...@autinity.de
web: www.autinity.de
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2655031
Gert Kello
>> how can I find out which changes in that file were made by me and
>> which changes came from the newer revision I just got? I can
After You update Your working copy, *ALL* remaining changes in WC are made by *"You"*. The merged ones are not changes, they are part of working copy BASE now.
If You want to see changes updated into working copy, then, as usually, get diff from "Log" window.
Gert
Bob Archer
> and
> >> which changes came from the newer revision I just got? I can
>
> I actually fail to understand this statement:
> After You update Your working copy, *ALL* remaining changes in WC
> are made by *"You"*. The merged ones are not changes, they are part
> of working copy BASE now.
Doh! Good point. But, I think he is saying he wants to see what changes were merged in that he didn't originally have in BASE.
In other words... he has myfile.txt in his WC with a BASE or r100. He works on it for a while and then does an update. He sees that myfile.txt was "Updated" with no conflicts. No his BASE is r123... he wants to right click on the file in WC and see the diffs that he just brought down, in other words what changes were made between r100 and r123. There is no way to do that diff in regards to the working copy file. (Which I totally understand)
> If You want to see changes updated into working copy, then, as
> usually, get diff from "Log" window.
>
I also advised this... ;)
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2655201
Bob Archer
> > and
> > >> which changes came from the newer revision I just got? I can
> >
> > I actually fail to understand this statement:
> > After You update Your working copy, *ALL* remaining changes in WC
> > are made by *"You"*. The merged ones are not changes, they are
> part
> > of working copy BASE now.
>
> Doh! Good point. But, I think he is saying he wants to see what
> changes were merged in that he didn't originally have in BASE.
>
> In other words... he has myfile.txt in his WC with a BASE or r100.
> He works on it for a while and then does an update. He sees that
> myfile.txt was "Updated" with no conflicts. No his BASE is r123...
> he wants to right click on the file in WC and see the diffs that he
> just brought down, in other words what changes were made between
> r100 and r123. There is no way to do that diff in regards to the
> working copy file. (Which I totally understand)
>
>
> > If You want to see changes updated into working copy, then, as
> > usually, get diff from "Log" window.
> >
>
> I also advised this... ;)
>
> BOb
Of course, if he is talking about a "merge" which is the subject of this thread... then he is doing it wrong. You should NOT be merging into a dirty (one with local changes) working copy.
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2655202
Stefan Wild
>> Doh! Good point. But, I think he is saying he wants to see what
>> changes were merged in that he didn't originally have in BASE.
>>
>> In other words... he has myfile.txt in his WC with a BASE or r100.
>> He works on it for a while and then does an update. He sees that
>> myfile.txt was "Updated" with no conflicts. No his BASE is r123...
>> he wants to right click on the file in WC and see the diffs that he
>> just brought down, in other words what changes were made between
>> r100 and r123. There is no way to do that diff in regards to the
>> working copy file. (Which I totally understand)
>
If it's really not possible as you said, I have to try it like discussed last week.
--
Mit freundlichen Grüßen
Stefan Wild
autinity systems GmbH
Neefestraße 42
D-09119 Chemnitz
Amtsgericht Chemnitz HRB: 21552
Telefon: +49 (0) 371 918897-50
Fax: +49 (0) 371 918897-49
email: stefa...@autinity.de
web: www.autinity.de
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2655967
spongman
> On 8/19/2010 1:59 PM, spongman wrote:
> >
> > repository, and this button does not disambiguate between them.
>
> > the term 'local' sin't much better - does it refer to my working copy
> > before the merge, the working copy after the failed merge, some other
> > local copy?
>
> between a working copy and the repository. When you do a merge, you
> "merge two different trees" option, but in that case, both repo URLs
> define the "source" of the merge; you're still merging into your working
> copy).
>
> process needs to be on the window; the terms are clear enough if you
> read the TSVN help file.
ok, it's been a year. i've read this thread, i've read the docs.
I know it's all explained in the help file and if you're intimately
familiar with the inner workings of the SVN codebase it's probably as
clear as day, but every time this dialog appears I still find it
ambiguous.
It could be that I'm just an idiot. However, i don't seem to be the
only one that has this problem.
Above you state that a merge is done between a "working copy and the
repository", but isn't a working copy always associated with a
repository (making the 'repository' term ambiguous)? if not, is that a
common use-case? is it a common enough use-case that knowledge of it
precludes understanding of a core user-interface element?
Please ask yourself: "should the user interface only make sense to
people who have read (or wrote) the help file?"
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855268
Dave Huang
> Above you state that a merge is done between a "working copy and the
> repository", but isn't a working copy always associated with a
> repository (making the 'repository' term ambiguous)? if not, is that a
> common use-case? is it a common enough use-case that knowledge of it
> precludes understanding of a core user-interface element?
Well, yes, a working copy is *associated* with a repository, but I think the distinction between a working copy and a repository is still clear. If you're going to say two terms are confusingly similar simply because there's some sort of association between them, you're going to eliminate a lot of words from the language.
> Please ask yourself: "should the user interface only make sense to
> people who have read (or wrote) the help file?"
"should the user interface only make sense to people who have read the help file?" Yes. Some things are complex and take more than 3 words to explain. I see no problem whatsoever to make reading a section of the help file a prerequisite for using the software. "should the user interface only make sense to people who wrote the help file?" Of course not.
If you think the help file isn't clear enough, and you're still confused even after reading it, then I think the help file could use improvement and clarification. Please ask questions about what you don't understand, and/or offer suggestions for changes.
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855290
spongman
> ...
> I think the distinction between a working copy and a repository is still clear.
I'm sure you do.
However, for myself and several others who have taken the time to
bring it up, it is definitely not clear.
> If you're going to say two terms are confusingly similar simply because there's some sort of association between them, you're going to eliminate a lot of words from the language.
> "should the user interface only make sense to people who have read the help file?" Yes.
wow. if that's the case, you might want to address some of these
entries on the about page (http://tortoisesvn.net/about.html):
- Easy to use
- descriptive dialogs, constantly improved due to user feedback
really. this isn't some kind of ad-hominem attack. i'm just trying to
give some feedback from the point of view of a neophyte that might
help improve the usability of the product.
might it be possible to show, in the dialog, the path/URL/version of
both the 'local' and 'repository' entries that conflicted? that would
certainly go a long way to clarify which term refers to which entry.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855302
Stefan Küng
> On Oct 14, 12:49 pm, Dave Huang<k...@azeotrope.org> wrote:
>> ... I think the distinction between a working copy and a repository
>> is still clear.
>
> I'm sure you do.
>
> However, for myself and several others who have taken the time to
> bring it up, it is definitely not clear.
>
>> If you're going to say two terms are confusingly similar simply
>> because there's some sort of association between them, you're going
>> to eliminate a lot of words from the language.
>
>
>> "should the user interface only make sense to people who have read
>> the help file?" Yes.
>
> wow. if that's the case, you might want to address some of these
> entries on the about page (http://tortoisesvn.net/about.html):
>
> - Easy to use - descriptive dialogs, constantly improved due to user
> feedback
>
> really. this isn't some kind of ad-hominem attack. i'm just trying
> to give some feedback from the point of view of a neophyte that
> might help improve the usability of the product.
>
> might it be possible to show, in the dialog, the path/URL/version of
> both the 'local' and 'repository' entries that conflicted? that
> would certainly go a long way to clarify which term refers to which
> entry.
You've complained that the dialog is confusing. And that you're confused
about the difference between 'repository' and 'working copy'.
Those two terms are maybe the most important terms when you're using any
version control system. I'm sorry, but if you don't understand what a
repository and a working copy is and how they're connected, then I don't
see how we could make that dialog any easier to understand.
I don't think you can really use any version control system (not just
SVN but all others as well) if you don't understand those two terms.
Do you have any suggestions on how that dialog could be improved?
Just telling that it's not clear won't help at all.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855304
spongman
> > might it be possible to show, in the dialog, the path/URL/version of
> > both the 'local' and 'repository' entries that conflicted? that
> > would certainly go a long way to clarify which term refers to which
> > entry.
>
> You've complained that the dialog is confusing. And that you're confused
> about the difference between 'repository' and 'working copy'.
> Those two terms are maybe the most important terms when you're using any
> version control system. I'm sorry, but if you don't understand what a
> repository and a working copy is and how they're connected, then I don't
> see how we could make that dialog any easier to understand.
I understand what those terms mean. However, when you're doing a merge
there are two repositories involved (the repository you're merging,
and the repository associated with the working copy), and the meaning
of the 'local' term is ambiguous - does it refer to the state of the
working copy pre-merge or post-merge?
> I don't think you can really use any version control system (not just
> SVN but all others as well) if you don't understand those two terms.
>
> Do you have any suggestions on how that dialog could be improved?
> Just telling that it's not clear won't help at all.
yes, please read the paragraph you quoted from my last post, above.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855319
Andy Levy
> On Oct 14, 1:31 pm, Stefan Küng <tortoise...@gmail.com> wrote:
>> > might it be possible to show, in the dialog, the path/URL/version of
>> > both the 'local' and 'repository' entries that conflicted? that
>> > would certainly go a long way to clarify which term refers to which
>> > entry.
>>
>> You've complained that the dialog is confusing. And that you're confused
>> about the difference between 'repository' and 'working copy'.
>> Those two terms are maybe the most important terms when you're using any
>> version control system. I'm sorry, but if you don't understand what a
>> repository and a working copy is and how they're connected, then I don't
>> see how we could make that dialog any easier to understand.
>
> I understand what those terms mean. However, when you're doing a merge
> there are two repositories involved (the repository you're merging,
> and the repository associated with the working copy),
Subversion does not support merging between two repositories, so
either your understanding or your terminology *is* wrong somewhere
along the way here.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855323
spongman
> Subversion does not support merging between two repositories, so
> either your understanding or your terminology *is* wrong somewhere
> along the way here.
i am aware of that. however the working copy has an associated
repository, and, for me at least, it's not obvious from the wording of
the dialog that 'repository' does NOT refer to the repository of the
working copy.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855325
Stefan Küng
> On Oct 14, 1:31 pm, Stefan Küng<tortoise...@gmail.com> wrote:
>>> might it be possible to show, in the dialog, the path/URL/version of
>>> both the 'local' and 'repository' entries that conflicted? that
>>> would certainly go a long way to clarify which term refers to which
>>> entry.
>>
>> You've complained that the dialog is confusing. And that you're confused
>> about the difference between 'repository' and 'working copy'.
>> Those two terms are maybe the most important terms when you're using any
>> version control system. I'm sorry, but if you don't understand what a
>> repository and a working copy is and how they're connected, then I don't
>> see how we could make that dialog any easier to understand.
>
> I understand what those terms mean. However, when you're doing a merge
> there are two repositories involved (the repository you're merging,
> and the repository associated with the working copy), and the meaning
> of the 'local' term is ambiguous - does it refer to the state of the
> working copy pre-merge or post-merge?
When you're merging, only _one_ repository is involved. This is SVN, not
a DVCS where you have multiple repositories.
And how is 'local' ambiguous?
The dialog asks you to choose which of the conflicting parts you want to
use. How can that refer to something post-merge? You can't choose
something that doesn't exist yet.
>> I don't think you can really use any version control system (not just
>> SVN but all others as well) if you don't understand those two terms.
>>
>> Do you have any suggestions on how that dialog could be improved?
>> Just telling that it's not clear won't help at all.
>
> yes, please read the paragraph you quoted from my last post, above.
I did. And you're not helping with such answers.
Please read your own paragraph yourself. You have not mentioned any
changes you want in that dialog to make it more clear or better to
understand. You only mentioned that it's not clear to you.
So again: how would you change that dialog to improve it?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855327
Stefan Küng
> On Oct 14, 1:52 pm, Andy Levy<andy.l...@gmail.com> wrote:
>> Subversion does not support merging between two repositories, so
>> either your understanding or your terminology *is* wrong somewhere
>> along the way here.
>
> i am aware of that. however the working copy has an associated
> repository, and, for me at least, it's not obvious from the wording of
> the dialog that 'repository' does NOT refer to the repository of the
> working copy.
I think you're confusing something here. Unlike DVCS, Subversion does
not have a local repository.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855329
spongman
> > yes, please read the paragraph you quoted from my last post, above.
>
> I did. And you're not helping with such answers.
> Please read your own paragraph yourself. You have not mentioned any
> changes you want in that dialog to make it more clear or better to
> understand. You only mentioned that it's not clear to you.
>
> So again: how would you change that dialog to improve it?
again, for the 3rd time:
>>> might it be possible to show, in the dialog, the path/URL/version of
>>> both the 'local' and 'repository' entries that conflicted?
maybe my English isn't clear?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855333
spongman
> I think you're confusing something here. Unlike DVCS, Subversion does
> not have a local repository.
yeah, i understand that. but the working copy has a repository, right?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855334
Stefan Küng
> On Oct 14, 2:11 pm, Stefan Küng<tortoise...@gmail.com> wrote:
>> I think you're confusing something here. Unlike DVCS, Subversion does
>> not have a local repository.
>
> yeah, i understand that. but the working copy has a repository, right?
Quote:
Unlike DVCS, Subversion does
not have a local repository.
The working copy does not have a repository. It only knows where the
repository is (it knows the url of the repository to which it can
connect to).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855336
spongman
> On 14.10.2011 23:23, spongman wrote:
>
> > On Oct 14, 2:11 pm, Stefan Küng<tortoise...@gmail.com> wrote:
> >> I think you're confusing something here. Unlike DVCS, Subversion does
> >> not have a local repository.
>
> > yeah, i understand that. but the working copy has a repository, right?
>
> Quote:
> Unlike DVCS, Subversion does
> not have a local repository.
>
> The working copy does not have a repository. It only knows where the
> repository is (it knows the url of the repository to which it can
> connect to).
yeah, that's what I mean by 'has a repository'.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855340
Stefan Küng
> On Oct 14, 1:58 pm, Stefan Küng<tortoise...@gmail.com> wrote:
>>> yes, please read the paragraph you quoted from my last post, above.
>>
>> I did. And you're not helping with such answers.
>> Please read your own paragraph yourself. You have not mentioned any
>> changes you want in that dialog to make it more clear or better to
>> understand. You only mentioned that it's not clear to you.
>>
>> So again: how would you change that dialog to improve it?
>
> again, for the 3rd time:
>
>>>> might it be possible to show, in the dialog, the path/URL/version of
>>>> both the 'local' and 'repository' entries that conflicted?
>
> maybe my English isn't clear?
Well, you mentioned that in a month old post. I only read your current
posts. You didn't quote that old, old post, and you didn't quote
anything from that post.
So sorry, but I don't keep such old posts in my inbox.
And the dialog already shows you the file that the conflict occurs on.
The url of the parts you want to merge, that's the url you entered in
the merge dialog.
I don't think that would really improve the dialog.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855341
Stefan Küng
> On Oct 14, 2:26 pm, Stefan Küng<tortoise...@gmail.com> wrote:
>> On 14.10.2011 23:23, spongman wrote:
>>
>>> On Oct 14, 2:11 pm, Stefan Küng<tortoise...@gmail.com> wrote:
>>>> I think you're confusing something here. Unlike DVCS, Subversion does
>>>> not have a local repository.
>>
>>> yeah, i understand that. but the working copy has a repository, right?
>>
>> Quote:
>> Unlike DVCS, Subversion does
>> not have a local repository.
>>
>> The working copy does not have a repository. It only knows where the
>> repository is (it knows the url of the repository to which it can
>> connect to).
>
> yeah, that's what I mean by 'has a repository'.
And that's the same repository you're merging from. So there are no two
repositories, only one.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855342
Dave Huang
> On Oct 14, 12:49 pm, Dave Huang <k...@azeotrope.org> wrote:
> > ... I think the distinction between a working copy and a repository
> > is still clear.
>
> I'm sure you do.
>
> However, for myself and several others who have taken the time to
> bring it up, it is definitely not clear.
Did you read this section of the help file?
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-qs-basics.html
(or since TortoiseSVN is a Subversion client, the Subversion
documentation itself is also useful for learning about general concepts
that are important to know:
http://svnbook.red-bean.com/en/1.6/svn.basic.version-control-basics.html)
> > "should the user interface only make sense to people who have read
> > the help file?" Yes.
>
> wow. if that's the case, you might want to address some of these
> entries on the about page (http://tortoisesvn.net/about.html):
>
> - Easy to use
>- descriptive dialogs, constantly improved due to user
> feedback
I don't think "descriptive dialogs" means that the dialog needs to have
have three paragraphs of text explaining what a repository is, what a
local working copy is, and the difference between the two.
> really. this isn't some kind of ad-hominem attack. i'm just trying
> to give some feedback from the point of view of a neophyte that
> might help improve the usability of the product.
That's great, but I don't think "I shouldn't be forced to read the
manual" is usable or useful feedback. Now your next paragraph is
something that's actually a concrete suggestion. This thread is pretty
old and I don't remember where it ended up, but I'm pretty sure none of
the other people saying that the dialog was confusing gave any actual
real suggestions--congrats, you're the first!
> might it be possible to show, in the dialog, the path/URL/version of
> both the 'local' and 'repository' entries that conflicted? that
> would certainly go a long way to clarify which term refers to which
> entry.
I don't know, as I'm just a user, not a TSVN developer, but it certainly
seems like that's possible. The dialog already shows the local path of
the file that has conflicting changes (first line in the dialog:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/images/MergeConflictCallback.png).
I'm not really sure what else can be shown there that isn't a reminder
of what you already know though. You can already get the nitty gritty
details of the conflict by clicking the "Edit conflict" button, but the
information you get from that is definitely too much to show on the
dialog itself. You could show the URL of the repository, but you should
already know that--you specified it in the second page of the Merge
process (the "Merge revision range" page). You could show the revision
numbers that caused the conflict, but again, that's something you
specified yourself on the "Merge revision range" page.
Perhaps having a reminder of that information would be nice, but
personally, I don't even know what I would use that info for. When I
have a merge conflict, 95+% of the time, I have no idea whether I want
to prefer local or repository; it's probably neither, and I need to use
"Edit conflict" and decide what needs to be done--I barely look at the
Resolve Conflict window. The other <5% of the time, I know the conflict
is due to some unimportant change, like an embedded timestamp, or the
IDE shuffling some lines around for no good reason. Or how MS Office
likes to modify an Excel file when you simply open it. In those cases, I
know that I want the changes that I'm merging in, so I use "Prefer
repository".
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+
PL++
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855343
spongman
> On 14.10.2011 23:21, spongman wrote:
> Well, you mentioned that in a month old post.
what? i wrote it 109 minutes ago, here:
https://groups.google.com/group/tortoisesvn/msg/a2ceec597c0fabff
> And the dialog already shows you the file that the conflict occurs on.
> The url of the parts you want to merge, that's the url you entered in
> the merge dialog.
it shows some of those things, but it doesn't clarify which versions/
paths 'local' and 'repository' refer to.
> I don't think that would really improve the dialog.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855347
spongman
> And that's the same repository you're merging from. So there are no two
> repositories, only one.
the problem is not that there are two different repositories, there
aren't.
the problem is that there are two different buttons that both could
refer to things that have (or are) repositories.
they refer to two different locations in the same repository.
ambiguous.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855348
Jean-Marc van Leerdam
Op 14 okt. 2011 23:46 schreef "spongman" <pie...@gmail.com> het volgende:
>
> On Oct 14, 2:34 pm, Stefan Küng <tortoise...@gmail.com> wrote:
> > And that's the same repository you're merging from. So there are no two
> > repositories, only one.
>
> the problem is not that there are two different repositories, there
> aren't.
>
> the problem is that there are two different buttons that both could
> refer to things that have (or are) repositories.
>
> they refer to two different locations in the same repository.
> ambiguous.
No, use local means 'use the changes present in my working copy'. And use repository means 'use the changes coming in from the merged source' (if I understand correctly). I don't see an ambiguity.
Regards,
Jean-Marc.
Stefan Küng
>
> Op 14 okt. 2011 23:46 schreef "spongman" <pie...@gmail.com
> > > And that's the same repository you're merging from. So there are no two
> > > repositories, only one.
> >
> > the problem is not that there are two different repositories, there
> > aren't.
> >
> > the problem is that there are two different buttons that both could
> > refer to things that have (or are) repositories.
> >
> > they refer to two different locations in the same repository.
> > ambiguous.
>
> No, use local means 'use the changes present in my working copy'. And
> use repository means 'use the changes coming in from the merged source'
> (if I understand correctly). I don't see an ambiguity.
exactly.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855354
Felix Saphir
> On Oct 14, 2:33 pm, Stefan Küng<tortoise...@gmail.com> wrote:
>
>> And the dialog already shows you the file that the conflict occurs on.
>> The url of the parts you want to merge, that's the url you entered in
>> the merge dialog.
>
> it shows some of those things, but it doesn't clarify which versions/
> paths 'local' and 'repository' refer to.
Standard question: What would the user gain? Keep in mind, that he or
she is currently merging their own changed files from a known
repository. They usually know their own changes, and the greatest worry
would probably be a correct merge. How would your proposed change ease
that situation?
Felix
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855358
spongman
> Am 14.10.2011 23:43, schrieb spongman:
>
> > On Oct 14, 2:33 pm, Stefan Küng<tortoise...@gmail.com> wrote:
>
> >> And the dialog already shows you the file that the conflict occurs on.
> >> The url of the parts you want to merge, that's the url you entered in
> >> the merge dialog.
>
> > it shows some of those things, but it doesn't clarify which versions/
> > paths 'local' and 'repository' refer to.
>
> Standard question: What would the user gain? Keep in mind, that he or
> she is currently merging their own changed files from a known
> repository. They usually know their own changes, and the greatest worry
> would probably be a correct merge. How would your proposed change ease
> that situation?
>
> Felix
>
>
> To unsubscribe from this discussion, e-mail: [users-unsubscr...@tortoisesvn.tigris.org].
when I merge I'm rarely merging /just/ my changes. i'm usually merging
sets of changes from multiple people/teams.
however, i don't really see why that's relevant to ambiguity of those
buttons.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855590
Felix Saphir
> On Oct 14, 4:13 pm, Felix Saphir<felix.sap...@kantarmedia.com>
> wrote:
>> Am 14.10.2011 23:43, schrieb spongman:
>>> On Oct 14, 2:33 pm, Stefan Küng<tortoise...@gmail.com> wrote:
>>
>>>> And the dialog already shows you the file that the conflict
>>>> occurs on. The url of the parts you want to merge, that's the
>>>> url you entered in the merge dialog.
>>
>>> it shows some of those things, but it doesn't clarify which
>>> versions/ paths 'local' and 'repository' refer to.
>>
>> Standard question: What would the user gain? Keep in mind, that he
>> or she is currently merging their own changed files from a known
>> repository. They usually know their own changes, and the greatest
>> worry would probably be a correct merge. How would your proposed
>> change ease that situation?
>>
> merging sets of changes from multiple people/teams.
>
> however, i don't really see why that's relevant to ambiguity of
> those buttons.
You don't have to. I just thought, being constructive might help your
case more than complaining.
Felix
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855943
Bob Archer
> > Subversion does not support merging between two repositories, so
> > either your understanding or your terminology *is* wrong somewhere
> > along the way here.
>
> i am aware of that. however the working copy has an associated repository,
> and, for me at least, it's not obvious from the wording of the dialog that
> 'repository' does NOT refer to the repository of the working copy.
Local is the working copy that is the target of the merge.
Didn't it used to say "Mine" "Theirs"?
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2857872
Stefan Küng
>> On Oct 14, 1:52 pm, Andy Levy<andy.l...@gmail.com> wrote:
>>> Subversion does not support merging between two repositories, so
>>> either your understanding or your terminology *is* wrong somewhere
>>> along the way here.
>>
>> i am aware of that. however the working copy has an associated repository,
>> and, for me at least, it's not obvious from the wording of the dialog that
>> 'repository' does NOT refer to the repository of the working copy.
>
> Local is the working copy that is the target of the merge.
>
> Didn't it used to say "Mine" "Theirs"?
Yes, but apparently that was even more confusing.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2857873
Bob Archer
> > On 14.10.2011 23:21, spongman wrote:
> > Well, you mentioned that in a month old post.
>
> what? i wrote it 109 minutes ago, here:
>
> https://groups.google.com/group/tortoisesvn/msg/a2ceec597c0fabff
>
> > And the dialog already shows you the file that the conflict occurs on.
> > The url of the parts you want to merge, that's the url you entered in
> > the merge dialog.
>
> it shows some of those things, but it doesn't clarify which versions/ paths
> 'local' and 'repository' refer to.
>
> > I don't think that would really improve the dialog.
My 3 way merge tool shows the path to the local copy, the repository copy and the merged result.
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2857874
Bob Archer
> >> On Oct 14, 1:52 pm, Andy Levy<andy.l...@gmail.com> wrote:
> >>> Subversion does not support merging between two repositories, so
> >>> either your understanding or your terminology *is* wrong somewhere
> >>> along the way here.
> >>
> >> i am aware of that. however the working copy has an associated
> >> repository, and, for me at least, it's not obvious from the wording
> >> of the dialog that 'repository' does NOT refer to the repository of the
> working copy.
> >
> > Local is the working copy that is the target of the merge.
> >
> > Didn't it used to say "Mine" "Theirs"?
>
> Yes, but apparently that was even more confusing.
>
> Stefan
I can see if I am merging from a path in the repository into a working directory that is a checkout of another path in the repository that target working copy isn't really "mine" since I might not have written any of the code.
Mine = Local = Merge Target
Thiers = Repository = Merge Source
BOb
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2857875
Floele
confusing.
And it doesn't help that "edit conflict" then uses the terms "mine"
and "theirs".
Some quick comments from my side:
> "should the user interface only make sense to people who have read the help file?" Yes.
Not at all. A help file should be supplemental only. In the case of
merging, a rather complex task, even for developers and apparently
hard to get right, the availability of a decent documentation is
important. And you should certainly read a bit of it before merging.
Still, even if you understand the concept thanks to the help file,
next time you merge you may have forgotten which button performs which
action, which is all too easy with the given labels. Merging is hard
enough already, don't make it any harder by replacing intuitive dialog
design with a comprehensive help file.
When I first encountered the dialog, I didn't know which button would
do what I wanted to do. And worse, the dialog didn't give me any clues
to figure it out, especially since "edit conflict" uses other terms.
Yes, there is a nice "Help" button, but that is easily being
overlooked as most applications which such buttons do not provide any
useful help content *at all*. Same as you can be banner blind, I
consider myself "help button blind". Even knowing that the help file
contains the information I am interested in, I'd prefer not to open
the help file each time and have some clues directly in the dialog.
To make the discussion a bit more constructive, I'd imagine a dialog
layout like this, that would help me quite a bit: http://i56.tinypic.com/e7nj9s.png
Additionally, the paths right of the buttons could be a link to the
log of that file, since it may help to understand the reason for the
conflict or changes to the file (or even who made changes). What do
you think?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2857895
Wayne Johnson
"it sucks because it confuses me fix it."
>
> To make the discussion a bit more constructive, I'd imagine a dialog
> layout like this, that would help me quite a bit:
> http://i56.tinypic.com/e7nj9s.png
I don't think that paths add any helpful information. I don't understand
how local can mean anything other than the working copy that you are
merging into. How can the repository be any path other than the one that
contains the path you just entered into the dialog box to start the
merge?
How can you possibly merge 2 things together unless you understand what
they are? You can probably get away with checking things in or out
without having really knowing what you are doing. However, if you are
merging stuff you had better understand what you are doing and it's
obvious from at least spongman's comments that there are some real
misunderstandings of the what how subversion works, fundamental
misunderstandings.
To use subversion effectively you really *must* know what is repository
is and what a working copy is and how they are different. You also need
to understand that subversion commands (for the most part) do not update
the repository until you actually commit the changes. I would hazard a
guess that at least 75% of the help requests that come across the list
are because the user does not understand these fundamentals.
> Additionally, the paths right of the buttons could be a link to the
> log of that file, since it may help to understand the reason for the
> conflict or changes to the file (or even who made changes). What do
> you think?
A list of the relevant log messages might be helpful. It would save the
step of opening openning a log list. This would have to be weighed
against the increased net traffic required to fetch the log. I don't
know enough to answer that question.
Wayne
>
> ------------------------------------------------------
>
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessag
> eId=2857895
>
> To unsubscribe from this discussion, e-mail: [users-
> unsub...@tortoisesvn.tigris.org].
>
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858249
Floele
> how local can mean anything other than the working copy that you are
> merging into. How can the repository be any path other than the one that
> contains the path you just entered into the dialog box to start the
> merge?
It may be obvious if you have read all 49 messages of this discussion,
at this point you will probably not be able to confuse them easily.
Still, the problem is my brain works this way:
I want to merge changes from version X into trunk. So I start the
merge assistant in my trunk folder, then select version X in "URL to
merge from". Then click "next" and "merge". With a bit of luck, it
will just do what I want it to do. If it's not that easy I'll get the
dreaded conflict dialog. Now I might know that I either want to use
the trunk or version X state of the conflicted file. Problem is, that
this conception does not directly map to "Local" and "repository". I
can then guess that "repository" is version X, but I'd like to be
reassured that this is indeed the case. Or I might actually be
confused because of the new terms. They have not been used in the
assistant, it uses "URL to merge from" and "Working copy". In fact you
got all these terms below, the "inconsistency" (they are certainly not
factually incorrect) does not help:
My concept "Merge source, version X", terms used in TSVN: URL to merge
from - Repository - Theirs
My concept "Merge target, trunk", terms used in TSVN: Working copy -
Local - Mine
> How can you possibly merge 2 things together unless you understand what
> they are?
I can't, but I do know what I want to merge.
> However, if you are merging stuff you had better understand what you are doing and it's
> obvious from at least spongman's comments that there are some real
> misunderstandings of the what how subversion works, fundamental
> misunderstandings.
What fundamental misunderstandings would I be a victim of?
> To use subversion effectively you really *must* know what is repository
> is and what a working copy is and how they are different.
I do and still I believe that the dialog does not support me with my
task optimally.
> A list of the relevant log messages might be helpful. It would save the
> step of opening openning a log list. This would have to be weighed
> against the increased net traffic required to fetch the log.
I'd only want to have the list loaded when I click on the link, so it
should not cause more traffic. It's just easier than going to the
files manually.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858487
Wayne Johnson
> What fundamental misunderstandings would I be a victim of?
>
I don't know that you have fallen victim of any misunderstandings.
Complaints in earlier posts seem to be confusing the concept of working
copies, repositories and what the merge was actually modifying.
Wayne
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858603
Simon Large
> Thank-you for including something constructive instead of just saying
> "it sucks because it confuses me fix it."
+1
>> To make the discussion a bit more constructive, I'd imagine a dialog
>> layout like this, that would help me quite a bit:
>> http://i56.tinypic.com/e7nj9s.png
This screenshot is based on 1.6 I think, although that dialog has not
changed a great deal in 1.7. This is not a new problem - it has been
there for at least the last 2 years.
OK, I hate to admit it but when I think about it again, I'm confused
too, and I wrote the docs, dammit! The root of the problem is that the
term 'merge' is overloaded.
When you update your working copy, repository changes are merged with
your local changes. In that situation the 'prefer local' and 'prefer
repository' make perfect sense. The instructions for generating that
screenshot are in fact based on doing a merge during update.
What we are talking about here is a merge from a different path into a
clean working copy. In that case both sets of changes (relative to the
branch point) are already committed in the repository and they being
merged in a working copy. There are no local changes (*) so the term
'prefer local' is indeed confusing. What it in fact means is the
repository changes for the working copy URL, so you go with what was
in your working copy rather than what is coming in from the merge
source - possibly obvious when you think about it, but you do have to
think about it, which is what people here are complaining about.
I can certainly fix the docs, but I'm unsure how to improve the dialog
as I cannot at the moment come up with an alternative button label.
Showing paths is one way, but only works when the paths are short, and
I'm not sure it makes it that much clearer anyway. Another option
would be to put tooltips on the buttons. Prefer Local could have
something like "Discard incoming lines which conflict and keep what is
already there" and Prefer Repository could have "Accept incoming lines
which conflict in preference to what is already there". I think those
descriptions apply equally well to the update merge and the, er, merge
merge.
OTOH the reason I have never bumped into this myself is that I have
never used those buttons. I would always use Edit Conflicts and
recommend others to do the same. Unless you know exactly what the
conflict is then it is dangerous to auto-resolve conflicting lines.
Simon
(*) there could be local changes if you merge into a modified working
copy (not recommended), or if you are merging several separate ranges,
but that is not what we are talking about.
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858628
Floele
> copies, repositories and what the merge was actually modifying.
I am not even sure that the previous posts indicate this
misunderstanding. So far I believe everyone here knows how merging
works, it's just that the terms being used for the different actions
are not straightforward.
> OK, I hate to admit it but when I think about it again, I'm confused
> too, and I wrote the docs, dammit!
Heh, glad to get some support from that side ;)
> merged in a working copy. There are no local changes (*) so the term
> 'prefer local' is indeed confusing.
I'd agree with that. When updating your working copy instead of
merging, it does indeed make more sense. I don't think I ever got this
dialog when upading the working copy though and can't seem to find
this situation in the docs either?
> but you do have to think about it, which is what people here are complaining about.
Thanks, that's pretty much to the point.
> Showing paths is one way, but only works when the paths are short,
You could shorten the paths though. There is a WINAPI function
available that omits parts of the path in the middle and keeps the
important information (start and end), at least for local file paths.
Don't know if it works for URLs.
> I'm not sure it makes it that much clearer anyway.
At least, it connects the buttons with information the user is
familiar with, that is the names of the repositories/branches/version
numbers.
> Another option would be to put tooltips on the buttons.
Since that is rarely done, I'd assume that no one would expect and
then find these tooltips.
> something like "Discard incoming lines which conflict and keep what is
> already there" and Prefer Repository could have "Accept incoming lines
> which conflict in preference to what is already there".
I must admit that this does not add much clarity, sounds kinda
complicated to me (sorry).
> OTOH the reason I have never bumped into this myself is that I have
> never used those buttons. I would always use Edit Conflicts
Yep, I'd agree with that as well, but IIRC, "edit conflicts" only uses
the not so helpful terms "mine" and "theirs". I many cases, "mine"
might apply to both sides or no side at all.
So I still like the solution with path information, but "edit
conflicts" might also need some adjustments.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858865
Stefan Küng
> On 18 October 2011 07:35, Wayne Johnson<wa...@zk.com> wrote:
>> Thank-you for including something constructive instead of just saying
>> "it sucks because it confuses me fix it."
>
> +1
>
>>> To make the discussion a bit more constructive, I'd imagine a dialog
>>> layout like this, that would help me quite a bit:
>>> http://i56.tinypic.com/e7nj9s.png
>
> This screenshot is based on 1.6 I think, although that dialog has not
> changed a great deal in 1.7. This is not a new problem - it has been
> there for at least the last 2 years.
>
> OK, I hate to admit it but when I think about it again, I'm confused
> too, and I wrote the docs, dammit! The root of the problem is that the
> term 'merge' is overloaded.
>
> When you update your working copy, repository changes are merged with
> your local changes. In that situation the 'prefer local' and 'prefer
> repository' make perfect sense. The instructions for generating that
> screenshot are in fact based on doing a merge during update.
>
> What we are talking about here is a merge from a different path into a
> clean working copy. In that case both sets of changes (relative to the
> branch point) are already committed in the repository and they being
> merged in a working copy. There are no local changes (*) so the term
> (*) there could be local changes if you merge into a modified working
> copy (not recommended), or if you are merging several separate ranges,
> but that is not what we are talking about.
That's not entirely true: a merge of multiple non-sequential revisions
is done in multiple steps. A conflict can then arise in a later step
where a local file already received changes from a previous merge step.
In that case, the local file is already modified.
Thought I had to point this out...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858872
spongman
> it's
> obvious from at least spongman's comments that there are some real
> misunderstandings of the what how subversion works, fundamental
> misunderstandings.
I'm pretty sure I understand quite well how subversion works. Could
you point to which comments lead you to believe otherwise?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858875
spongman
> My 3 way merge tool shows the path to the local copy, the repository copy and the merged result.
unfortunately, that doesn't help if
- you're using a different merge tool that doesn't use the same
terminology
- you're merging binary files
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858878
spongman
> Mine = Local = Merge Target
> Thiers = Repository = Merge Source
I'm a fan of 'Target' & 'Source'.
Those terms make perfect sense to me.
And apparently to the SVN doc writers:
"usage: 1. merge [-c M[,N...] | -r N:M ...] SOURCE[@REV]
[TARGET_WCPATH]"
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858879
Simon Large
I know. I sort of included that in 'merging several separate ranges'
but didn't make it clear that they were specified as a single merge
op. That case is still confusing for the user because as far as he is
concerned there are no local mods that he made himself.
I don't think we are any nearer to finding a way of clarify the button
text yet :-(
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858881
spongman
> I would always use Edit Conflicts and
> recommend others to do the same.
not an option if you're merging trees containing binary files. in that
case those buttons are your only option.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858882
Simon Large
> On Oct 18, 3:54 pm, Simon Large <simon.tortoise...@gmail.com> wrote:
>> I would always use Edit Conflicts and
>> recommend others to do the same.
>
> not an option if you're merging trees containing binary files. in that
> case those buttons are your only option.
Meh, fair point.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858883
Dave Huang
> On Oct 17, 11:35 pm, Wayne Johnson <wa...@zk.com> wrote:
>> it's
>> obvious from at least spongman's comments that there are some real
>> misunderstandings of the what how subversion works, fundamental
>> misunderstandings.
>
> I'm pretty sure I understand quite well how subversion works. Could
> you point to which comments lead you to believe otherwise?
----------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855302
On Oct 14, 12:49 pm, Dave Huang <k...@azeotrope.org> wrote:
> I think the distinction between a working copy and a repository is still clear.
I'm sure you do.
However, for myself and several others who have taken the time to
bring it up, it is definitely not clear.
----------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2855319
> However, when you're doing a merge
> there are two repositories involved (the repository you're merging,
> and the repository associated with the working copy)
----------------------------------------
Earlier you admit that the distinction between a working copy and a repository isn't clear to you. You later clarify that you understand that there's only one repository involved, but that since a working copy is associated with a repository, both can be referred to as a "repository". Your insistence on tying a WC to a repo in the context of a merge operation makes it sound like you don't quite get that the merge destination is the WC, and the repo that's associated with the WC isn't involved at all until you commit (which is not part of the merge).
Recall that we're talking about the conflict dialog that appears *when you do a merge*. Since the subject is merging, it doesn't really make sense to think about the repo that's associated with the WC that you're merging into.
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858884
spongman
> On Oct 19, 2011, at 12:02 PM, spongman wrote:
>
> > On Oct 17, 11:35 pm, Wayne Johnson <wa...@zk.com> wrote:
> >> it's
> >> obvious from at least spongman's comments that there are some real
> >> misunderstandings of the what how subversion works, fundamental
> >> misunderstandings.
>
> > I'm pretty sure I understand quite well how subversion works. Could
> > you point to which comments lead you to believe otherwise?
>
>
> On Oct 14, 12:49 pm, Dave Huang <k...@azeotrope.org> wrote:
>
> > I think the distinction between a working copy and a repository is still clear.
>
> I'm sure you do.
>
> However, for myself and several others who have taken the time to
> bring it up, it is definitely not clear.
>
> > However, when you're doing a merge
> > there are two repositories involved (the repository you're merging,
> > and the repository associated with the working copy)
>
> ----------------------------------------
>
> Earlier you admit that the distinction between a working copy and a repository isn't clear to you. You later clarify that you understand that there's only one repository involved, but that since a working copy is associated with a repository, both can be referred to as a "repository". Your insistence on tying a WC to a repo in the context of a merge operation makes it sound like you don't quite get that the merge destination is the WC, and the repo that's associated with the WC isn't involved at all until you commit (which is not part of the merge).
>
> Recall that we're talking about the conflict dialog that appears *when you do a merge*. Since the subject is merging, it doesn't really make sense to think about the repo that's associated with the WC that you're merging into.
>
> --
> Name: Dave Huang | Mammal, mammal / their names are called /
> FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
> Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
>
>
> To unsubscribe from this discussion, e-mail: [users-unsubscr...@tortoisesvn.tigris.org].
Yes, the distinction isn't clear to me in the context of that dialog.
This is what I have been saying all along, and is the reason for me
starting this thread in the first place. When I said "two
repositories", I'm sorry I wasn't clear, I meant to say "two
different, ambiguous references to the same repository" (I replaced
the references with the referenced). The fact that the two refer to
the same repository does not help to resolve the ambiguity.
I am aware that the target of the merge is the working copy. I'm aware
that the merge itself does not write anything to the repository. But
that does not change the fact that the working copy is, nevertheless,
associated with a repository. It's associated with it before the
merge, it's associated with it during the merge, and it's associate
with it after the merge. Just because the repository isn't touched
during the merge, doesn't mean that association goes away. However,
what you seem to be saying above, is that in order to make sense of
the dialog, the user must somehow magically remember to temporarily
forget about this association.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858898
Stefan Küng
> I am aware that the target of the merge is the working copy. I'm aware
> that the merge itself does not write anything to the repository. But
> that does not change the fact that the working copy is, nevertheless,
> associated with a repository. It's associated with it before the
> merge, it's associated with it during the merge, and it's associate
> with it after the merge. Just because the repository isn't touched
> during the merge, doesn't mean that association goes away. However,
> what you seem to be saying above, is that in order to make sense of
> the dialog, the user must somehow magically remember to temporarily
> forget about this association.
You don't have to forget about the association. But as was mentioned
several times now, it has nothing to do with the merge.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858899
spongman
> ... it has nothing to do with the merge.
really? surely the existence of the target working copy depends on
this association. you cannot have a working copy without it, right? As
far as I know (and I defer to you as the expert here) the link to/
association with the repository is part of what defines what a working
copy is. From the point of view of the user you're merging one branch
into another, both are associated with the repository and therefore
the term 'repository' could refer to either one.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858903
Stefan Küng
> On Oct 19, 11:13 am, Stefan Küng<tortoise...@gmail.com> wrote:
>> ... it has nothing to do with the merge.
>
> really? surely the existence of the target working copy depends on
> this association. you cannot have a working copy without it, right? As
> far as I know (and I defer to you as the expert here) the link to/
> association with the repository is part of what defines what a working
> copy is. From the point of view of the user you're merging one branch
> into another, both are associated with the repository and therefore
> the term 'repository' could refer to either one.
Yes, a working copy is associated with a repository. And a working copy
is the target of a merge operation. But again (and hopefully for the
last time): the associated repository of the target working copy has
nothing to do with the merge.
I repeat: the associated repository of the target working copy has
nothing to do with the merge.
Also, if we refer to a repository, we would mention 'repository' and not
'working copy'. But we always mention 'working copy'. So why do you
insist that a working copy and its repository are ambiguous?
In TSVN (and the SVN docs and CL client as well), there is not one
mention of 'working copy' where a repository is meant or vice versa.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858906
Dale McCoy
> From the point of view of the user
> the term 'repository' could refer to either one.
Yet again you try to tell us that "Every working copy is associated
with a repository. Therefore the term 'repository' is ambiguous, as it
could refer to either the working copy or the repository."
This is horribly disingenuous. Instead of "working copy" and
"repository", consider any two other nouns where one is associated
with the other. "Husband" and "wife", for example: Every husband is
associated with a wife. Therefore the term "wife" is ambiguous, as it
could refer to either the wife or the husband.
Dale McCoy
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858912
Floele
> the not so helpful terms "mine" and "theirs". I many cases, "mine"
> might apply to both sides or no side at all.
Just got the dialog again and checked. In fact, it is even worse.
TortoiseMerge does indeed use "Theirs" and "Mine" (confusing) but on
top of that, it shows "Theirs" on the left, while the corresponding
button "Prefer repo" is on the right and vice versa. That seems easy
to fix.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2859464
Bob Archer
> > On Oct 19, 11:13 am, Stefan Küng<tortoise...@gmail.com> wrote:
> >> ... it has nothing to do with the merge.
> >
> > really? surely the existence of the target working copy depends on
> > this association. you cannot have a working copy without it, right? As
> > far as I know (and I defer to you as the expert here) the link to/
> > association with the repository is part of what defines what a working
> > copy is. From the point of view of the user you're merging one branch
> > into another, both are associated with the repository and therefore
> > the term 'repository' could refer to either one.
>
> Yes, a working copy is associated with a repository. And a working copy is the
> target of a merge operation. But again (and hopefully for the last time): the
> associated repository of the target working copy has nothing to do with the
> merge.
> I repeat: the associated repository of the target working copy has nothing to
> do with the merge.
Yes and no. It depends on the merge you preform. If you do merge a range... the repository path associated to the current working copy is used as the SOURE2 of the merge. If you use the command line and do:
svn merge ^/MyProject/branches/MyFeature
There are two things implied.
1. The target to which the merge diff is applied... which is the pwd, your working copy
2. The source2 of the merge... this is inferred as the svn path or URL that the checkout points to.
You see in this in the command line help:
svn merge SOURCE1[@N] SOURCE2[@M] [TARGET_WCPATH]
So, when you don't specify SOURCE2 then the associated repository of the URL is what is used as SOURCE2.
I assume you mean to say, a merge doesn't ALWAYS use the URL of the associated repository path of the target working copy.
Assume an TSVN two tree merge... neither the From or To (not really accurate since the word TO implies target, but doesn't mean that here at all) where neither are in any way releated to the current working copy. The current working copy is nothing more than the target of the diff between SOURCE1 and SOURCE2. In that case neither SOURCE1 or SOURCE2 is really "Local"... they are both actually infact repository. Neither can one of the other be considered MINE or THEIRS.
If during an UPDATE there is a conflict then Local / Repository works perfectly fine. But not always true for a merge UNLESS the working copy is SOURCE2.
BOb
>
> Also, if we refer to a repository, we would mention 'repository' and not
> 'working copy'. But we always mention 'working copy'. So why do you insist
> that a working copy and its repository are ambiguous?
> In TSVN (and the SVN docs and CL client as well), there is not one mention of
> 'working copy' where a repository is meant or vice versa.
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> ------------------------------------------------------
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMess
> ageId=2858906
>
> To unsubscribe from this discussion, e-mail: [users-
> unsub...@tortoisesvn.tigris.org].
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2859736
Dave Huang
> Yes and no. It depends on the merge you preform. If you do merge a range... the repository path associated to the current working copy is used as the SOURE2 of the merge. If you use the command line and do:
>
> svn merge ^/MyProject/branches/MyFeature
>
> There are two things implied.
>
> 1. The target to which the merge diff is applied... which is the pwd, your working copy
> 2. The source2 of the merge... this is inferred as the svn path or URL that the checkout points to.
I suppose you're *technically* correct that the repo associated with the WC is used in that case, but that's only due to the "^" shortcut, which doesn't work in TSVN (I tried it, and it said "Error: 'C:\Users\Dave\AppData\Local\Temp' is not a working copy; I assume TSVN's current directory was set to the temp dir, rather than my WC dir). However, both source1 and source2 of the merge are derived from that path, not just source2. SVN merges always need two sources--what you said later about a merge basically applying the diff between Source1 and Source2 to the WC applies to the "svn merge ^/MyProject/branches/MyFeature" case too, not only the two-tree merge case. Source1 is basically rev 1 of ^/MyProject/branches/MyFeature and source2 is HEAD of ^/MyProject/branches/MyFeature.
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2859741
Dave Huang
> I suppose you're *technically* correct that the repo associated with the WC is used in that case, but that's only due to the "^" shortcut
Also, it could be argued that the "^" shortcut doesn't really represent the repo associated with the WC in the sense that spongman's using it--he later clarified that he meant that the dialog was ambiguous because "repository" could refer to two different paths in the same repo, one of which is the repo path associated with the WC. As we all seem to agree now, there's only one repo involved, and spongman's contention is that it's the multiple paths within that repo that are confusing. Since "^" refers to the repo itself, not to any path within it, it's simply a shortcut for typing the URL to the one and only repo root, and the full repo path associated with the WC is *not* used. You still have to specify the path yourself (e.g., the /MyProject/branches/MyFeature part).
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2859744
Bob Archer
> > Yes and no. It depends on the merge you preform. If you do merge a
> range... the repository path associated to the current working copy is used as
> the SOURE2 of the merge. If you use the command line and do:
> >
> > svn merge ^/MyProject/branches/MyFeature
> >
> > There are two things implied.
> >
> > 1. The target to which the merge diff is applied... which is the pwd,
> > your working copy 2. The source2 of the merge... this is inferred as the svn
> path or URL that the checkout points to.
>
> I suppose you're *technically* correct that the repo associated with the WC
> is used in that case, but that's only due to the "^" shortcut, which doesn't
> work in TSVN (I tried it, and it said "Error:
Yea, I know. Not the point. I could just of well have said:
svn merge http://myserver/myrepo/MyProject/branches/MyFeature
implies SOURCE2 and TARGET from the pwd which is a working copy. You are only specifying SOURCE1 or what TSVN calls "FROM" in its dialogs.
> 'C:\Users\Dave\AppData\Local\Temp' is not a working copy; I assume TSVN's
> current directory was set to the temp dir, rather than my WC dir). However,
> both source1 and source2 of the merge are derived from that path, not just
> source2. SVN merges always need two sources--what you said later about a
No, when you merge in TSVN you select SOURCE1, it is what you put in the "FROM" path in the TSVN dialog. It has nothing to do with the working copy or the working copy's associated svn path.
> merge basically applying the diff between Source1 and Source2 to the WC
> applies to the "svn merge ^/MyProject/branches/MyFeature" case too, not
> only the two-tree merge case. Source1 is basically rev 1 of
> ^/MyProject/branches/MyFeature and source2 is HEAD of
> ^/MyProject/branches/MyFeature.
Yes, I understand there are two sources. I think you missed my point.
BOb
Dave Huang
> Yea, I know. Not the point. I could just of well have said:
>
> svn merge http://myserver/myrepo/MyProject/branches/MyFeature
>
> implies SOURCE2 and TARGET from the pwd which is a working copy. You are only specifying SOURCE1 or what TSVN calls "FROM" in its dialogs.
>
>> 'C:\Users\Dave\AppData\Local\Temp' is not a working copy; I assume TSVN's
>> current directory was set to the temp dir, rather than my WC dir). However,
>> both source1 and source2 of the merge are derived from that path, not just
>> source2. SVN merges always need two sources--what you said later about a
>
> No, when you merge in TSVN you select SOURCE1, it is what you put in the "FROM" path in the TSVN dialog. It has nothing to do with the working copy or the working copy's associated svn path.
And in your previous message, you wrote:
> So, when you don't specify SOURCE2 then the associated repository of the URL is what is used as SOURCE2.
However, that's incorrect--"svn merge http://myserver/myrepo/MyProject/branches/MyFeature" with the command-line client is equivalent to TSVN's do a "Merge a range of revisions" with "URL to merge from" set to "http://myserver/myrepo/MyProject/branches/MyFeature" and "Revision range to merge" left blank.
TSVN says of the Revision range box, "To merge all revisions, leave the box empty," which isn't as explicit as the command-line client's "If no revision range is specified, the default range of 0:REV is used," but means the same thing. The CLI help also says, "'-r N:M' specifies a revision range to be merged. The difference between SOURCE@REV as it existed at revision N, and SOURCE@REV at it existed at revision M, is merged into TARGET_WCPATH."
Note that last sentence. So both SOURCEs are derived from http://myserver/myrepo/MyProject/branches/MyFeature: SOURCE1 is http://myserver/myrepo/MyProject/branches/MyFeature at revision 0, and SOURCE2 is http://myserver/myrepo/MyProject/branches/MyFeature at HEAD (with the added caveat of "If mergeinfo within TARGET_WCPATH indicates that revisions within the range were already merged, changes made in those revisions are not merged again.") In no case is the repo path associated with the WC used as either SOURCE1 or SOURCE2.
If it worked as you say, how would a merge do anything useful? Assume your WC has no local changes (as is the usual case during a merge), so your WC has the same contents as its associated repo path. And for simplicity, assume this is your first merge, so there's no mergeinfo. If you take the differences from some SOURCE URL and your WC's repo path, then apply that diff to your WC, you're going to try to double-apply every single difference between the two: conflicts galore.
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2859932