Joseph Galbraith <galb@vandyke.com> wrote on 01/19/2005 11:53:44 AM:
> Would it be unreasonable for TSVN to (optionally of course) stick
> a property in that recorded the merge path and revesion number.
> This property could then be read to populate the (default) values
> for the dialog next time.
>
> Maybe this doesn't work well in all merge scenerios, but in my
> merge scenerio, if TSVN set a property on the directory where
> I start the merge and recorded the path I merged from, and the
> revision I merged up to, and then restored the path from the
> property the next time I merged and restore the revision as the
> 'from' revision, it would sure make my life easier.
>
> Maybe another check box 'Store merge parameters in repository'
>
> Then, unless I'm doing a wierd merge, I get to just click go.
> If I'm doing a wierd merge, I uncheck the 'store merge parameters'
> check box, and setup my merge manually. (Maybe if the merge
> parameters where loaded from the repo, but the user changes
> them, they should be prompted to confirm if they want to
> store the new parameters.)
>
> Basically, what I'm thinking is that subversion could use a property
> to take care of the 'make sure you record your merge parameters
> in the commit message' advice automatically.
>
> I'm sure the SVN improved merging support will be far better then
> this when it comes along, but for the meantime, would this be
> very difficult to implement?
I was going to write up a detailed proposal for essentially the same
thing. Whatever is decided, I want to implement the same feature in
Subclipse.
The thing that is hanging me up at the moment is that I think there has to
be a way to make the name of the property unique to the branch. Otherwise,
if you have nested branches you would have property conflicts. Imagine
this scenario.
Subversion has a branch for the new locking feature. They are trying to
keep this branch up to date with trunk, so frequently do merges into the
branch from trunk. This feature would make that process very simple.
Now, suppose someone else starts a branch for another feature that depends
on the locking feature. So they have a branch from the locking branch
that they also want to keep in synh with that branch. Whenever they do a
merge in their branch, the property change from the locking branch would
be pulled into theirs and overwrite/conflict with their property. If
there were a way to come up with a property name that was unique then that
would solve the problem. I was thinking every folder has a unique ID you
could see in svn info, but that turned out to be false.
I think the one other problem with using a property is that after you do a
merge you will not be able to do a commit to your branch without doing an
update first. This is because you cannot commit a property change unless
the folder is at HEAD.
For this feature to work, if you specified HEAD as one of your revisions,
TSVN would have to retrieve and store the revision number of HEAD so that
it could be used later. I was thinking the property storage would look
like this. I would do it all as a single property.
FromURL=url://repos/project/branch
FromRev=100
ToURL=url://repos/project/branch
ToRev=HEAD
HEAD=200
FWIW, one thing we already do in Subclipse that helps is that when we
remember your URL's we do it by "project". That way the Merge and Switch
dialogs are not cluttered by every URL you have ever typed. That is the
one problem I have with TSVN, for those two dialogs. I do not mind it in
the Repo-browser, but in those dialogs it would be a great improvement to
limit what was remembered for you.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Jan 19 18:16:16 2005