I'll add more comments below, but I think I misunderstood the term
"automatic merge". I interpreted that as some existing
thread/process/whatever that comes into a working copy and issues the
update. I think I've got that wrong, although if I execute update, I
would expect the merge to occur....
On 2/13/07, Scott Nicolson <Scott.Nicolson@oscmar.co.nz> wrote:
>
>
> Merges will be automatic on any text file. I can change the mime type
> property of the files but this is just silly as more often than not the
> automatic merge will suffice. To clarify, say I am at revision 1 of a
> particular file, and I make updates and commit these but I can't because
> the HEAD is at revision 5. I am forced to update or branch. I choose
> to update and an automatic merge happens (no conflicts). Let say now
> that I did this in error and can't remember where I came from (I want to
> go back to 1). The only reason I could think I would want to do this is
> if I made the wrong decision and intended to branch instead. If the
> working copy new where it was before the merge I could then go back to
> that revision and create a branch from there. It is really just a book
> keeping thing. Perhaps too much work for little gain. Keeping in mind
> I am only forecasting problems not actually encountering these (yet).
>
Although I'm probably getting this wrong :), but I'll try again. If
I've got a bunch of local changes in my working copy, and I've decided
that I want to stop working in that area and branch to another
directory. You can revert your changes, so at least the working copy
is back up to date with the repository and then you can sort out from
which revision you want to branch. This would, however, lose your
changes.
One thing that is handy with Subversion is you can copy directories on
the server without needing to use the working copy. So, if that were
the case, I'd perform a copy (to the branches dir, or wherever you
store your branches) from the working copy or the head or whatever
revision you'll need.
If they don't want to include the changes that were just merged in, I
just can't think of anyway to automatically exclude them from this
without providing a revision number.
(opinion opinion) I still don't think it's that much to ask for them
to examine the log if they absolutely do not want the recent changes
in their branch. However, if the changes they are making are going
back into the trunk/originating branch, they will have to deal with it
at some point...
> >
> > 1) disable the automatic update.
>
> I think I can only do this by setting the mime-type property of all the
> files. Is there another way?
I cannot. This was based on my misunderstanding of your scenario.
Thus, treat it as a bad suggestion...
>
> > 2) update the automated process to only update the working copy if
> > there are no changes to it. If the status reports any changes, don't
> > do the update.
>
> I could do this with a script but the user interface we plan to use is
> tortoise, and again trying to accommodate the unaware user.
Again, bad suggestion stemming from my inability to correctly
understand your question. :)
> Sorry for the hypothetical questions and wasting time. I am just trying
> to give answers to difficult questions which may or may not actually be
> a problem.
>
Sorry for not understanding the original problem. :)
Perhaps your best bet is to document all these potential pitfalls and
your recommended approaches and make this available on a local
intranet site? It's been some time since I've used PVCS, so I can't
comment on how to emulate commonly-used PVCS activities in SVN.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Tue Feb 13 03:17:31 2007