Christophe Royer wrote on Sat, 14 May 2022 23:28 +00:00:
> Thank you for looking into this, taking the time to clean up the script
> and share your comments. Lessons learnt.
>
> I will likely revert (maybe manually) those invalid mergeinfo.
>
Sure. I recommend that you use a record-only reverse
Thank you for looking into this, taking the time to clean up the script
and share your comments. Lessons learnt.
I will likely revert (maybe manually) those invalid mergeinfo.
Still not quite sure of the consequences, and if this situation could be
detected. Maybe a defect or enhancement shoul
Christophe Royer wrote on Fri, May 13, 2022 at 10:45:14 -0700:
> Daniel, the first script I sent may confuse things a little, because of the
> tree conflict.
> Here is another script that avoid that issue. The problem is the same: it
> looks like the mergeinfo does not match the state of the branch
Daniel, the first script I sent may confuse things a little, because of
the tree conflict.
Here is another script that avoid that issue. The problem is the same:
it looks like the mergeinfo does not match the state of the branch.
-start of 2nd script
@ECHO off
REM -- Script to test handling
Shahaf ; users@subversion.apache.org
Subject: [External] Re: Question about mergeinfo and 2-url merge
Thank you Daniel, below is the script I used (line wrapping might mess up a few
lines, sorry)
As I was cleaning it up, I realized that in 1.6.17 (yes, still using it, and
where I saw the
Thank you Daniel, below is the script I used (line wrapping might mess
up a few lines, sorry)
As I was cleaning it up, I realized that in 1.6.17 (yes, still using it,
and where I saw the issue first) the behavior is different (2-url merge
gives me a tree conflict).
I am really tempted to del
Could you post the script, please? It's hard to answer your question
when it describes the details verbally rather than machine-readably.
It sounds like a supported scenario.
Cheers,
Daniel
Christophe Royer wrote on Fri, 06 May 2022 21:46 +00:00:
> I recently saw some mergeinfo that I can exp
I recently saw some mergeinfo that I can explain but still look wrong to
me. Not sure if it’s a wrong usage of svn, or possibly a defect, and so
far I have not seen any post about this. Here is the scenario (I have a
script, batch file for windows, if needed):
Seen first using svn 1.6.17,
> > Of course, --ignore-ancestry will also, well ignore ancestry,
> > and only do a diff. So, if you have a file with the same name
> > as an earlier file with the same path/name that is not
> > actually its parent you are going to get a bad merge.
>
> Sorry, I'm a bit lost here. Could you explain
> Of course, --ignore-ancestry will also, well ignore ancestry,
> and only do a diff. So, if you have a file with the same name
> as an earlier file with the same path/name that is not
> actually its parent you are going to get a bad merge.
Sorry, I'm a bit lost here. Could you explain this maybe
> > Another question: we do revision based merging, promoting
> > stories/goals not necessarily in the same order they were
> > committed in the trunk. Besides helping in tracing the
> > changes in the branch the the original logs, is there any
> > other utility in having the mergeinfo information?
> We are using svn 1.6 for a few weeks. Since then we faced the
> problem
> of the mergeinfo changing in files different from those that people
> were actually committing. We found out that we should always commit
> from the same level to stop this to happen.
>
> All good. I presume that we should
> Another question: we do revision based merging, promoting
> stories/goals not necessarily in the same order they were
> committed in the trunk. Besides helping in tracing the
> changes in the branch the the original logs, is there any
> other utility in having the mergeinfo information?
I can't
We are using svn 1.6 for a few weeks. Since then we faced the problem
of the mergeinfo changing in files different from those that people
were actually committing. We found out that we should always commit
from the same level to stop this to happen.
All good. I presume that we should have svn:merg
14 matches
Mail list logo
