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

Re: [TSVN] Re: Big Merge Push (was: [TSVN] Merging from deleted branch to trunk)

From: Joseph Galbraith <galb_at_vandyke.com>
Date: 2005-01-19 19:14:21 CET

Mark Phippard wrote:
> 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.

Would it be possible to get around this problem by properly
timing the 'property' update. I.e., TSVN first performs the
merge operation, potentially updating the 'merge parameters'
property with the information from the branch.

However, it then 'overwrites' the property, potential pulled
with the merge, with the correct information for the merge
now being performed. (TSVN might have to silently resolve
conflicts in the 'merge parameters' property.) I guess
this might cause problems if a merge were ever done outside
of TSVN though.

This case definitely complicates things.

What are the constraints on a property name? Another
potential resolution would be to embed the MD5 hash
of the relative path of the merge target in the property
name.

> 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

I would have just always resolved HEAD to it's real revision
number:

> FromURL=url://repos/project/branch
> FromRev=100
> ToURL=url://repos/project/branch
> ToRev=200

But it doesn't really matter (especially since I definitely
don't have the expertise w/ SVN or TSVN to implement
anything.)

Can the property change be done in the WC so that it
gets comitted at the same time as the rest of the merge?

Thanks,

Joseph

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Jan 19 19:19:24 2005

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

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