Eugene Kuleshov <eu@md.pp.ru> wrote on 12/05/2005 11:55:45 AM:
> > I do not underestimate that at all. That is really a different
problem in
> > my opinion. When looking at the history of a file on trunk for
example, I
> > do not see any direct relationship between that history and a branch,
> > which would have its own history and for which trunk may have been
merged
> > to that branch. You are expecting way too much here if you think this
can
> > be addressed.
>
> It would be really handy to be able to compare revision from
> history with branch using either starting revision or latest revision
> in this branch.
I agree completely. I just came to the conclusion that it is a different
issue than this one and can be dealt with differently. For example, there
could be a property like subclipse:branches added that has information
about branches and this could be used to better drive a Compare with
Branch option.
> You can also show unified diff in a plain text text editor (maybe
> with some basic outline), so user won't have to choose where to save
> file and then look where it was saved and open with some external
> editor (very annoying to me).
I just decided to leave that out for now. The file wouldn't be in your
workspace and I wasn't sure what API Eclipse offered for opening files in
editors that are not in your workspace. If you want to look into this and
send a patch, that would be great. Otherwise, I will come back to it
later.
> Right. I just suggesting to slightly change priorities. One still
> could use standard svn property editor to update this information. So,
> I think it is more important to handle properties on copy/tag/branch
> from the beginning.
I envisioned completing all 3 milestones before doing a release. I was
just logically separating what I thought the issues were. I think being
able to manually edit the properties is more important first.
> I wonder if repository restructuring would handle revisions and
> "copy from" information?
For the purpose that is used, it does not need to be updated. It is only
operations that need to know where stuff is @HEAD that needs accurate
information.
> How about add relative url (actually path from the repository root)
> to the properties for now? So, later we could pickup this
> information. It is better to have it here at least as a hint.
All I can say is maybe. I think it potentially adds a lot of complication
to the design. I want to be sure it is worth it.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue Dec 6 05:03:34 2005