>
> On Tue, Aug 04, 2020 at 06:37:07PM +, Jacob Weber wrote:
>> Hi there. I'm doing a merge which seems to be doing a very long-running
>> operation (over an hour so far) when it gets to the "Searching tree conflict
>> details" step. I'm wondering if
Hi there. I'm doing a merge which seems to be doing a very long-running
operation (over an hour so far) when it gets to the "Searching tree conflict
details" step. I'm wondering if there's any way to avoid this.
I'm merging from a branch X where a directory was removed, into a branch Y
where th
On Aug 27, 2013, at 1:39 PM, Mark Phippard wrote:
> On Tue, Aug 27, 2013 at 4:34 PM, Jacob Weber wrote:
> The next time I merge from trunk into my branch, how will SVN know not to
> merge X?
>
> Magic :)
>
> Internally, the code still does reintegrate. It just figures
According to the SVN 1.8 release notes: "Merging to-and-fro between two
branches in any order is possible using the automatic reintegration merge (the
"keep-alive dance" is no longer necessary)."
So say I merge from a branch into trunk (i.e. what used to be a reintegrate),
creating revision X.
On Oct 24, 2011, at 2:41 PM, Jacob Weber wrote:
> For example, if I give it two URLs:
> svn diff https://repos/proj1/dir1/dir2https://repos/proj2/dir1/dir2
>
> I get something like this, with the repository-relative paths in parentheses,
> prefixed by "
repos/proj1/
I get something like this, with no repository-relative paths in parentheses:
Index: dir1/dir2
===
--- dir1/dir2 (revision 103537)
+++ dir1/dir2 (revision 103538)
Jacob
On Oct 24, 2011, at 2:11 PM, Philip Martin
I want to pass the output of "svn diff OLD-URL NEW-URL" to a
code-review tool, but I need to include the full path of each file
in the ---/+++ headers.
The paths in the output always seem to be relative to the directories
you pass in. Is there a way to make it include the full paths?
Thanks,
J
I normally create branches from trunk, work on them, and eventually
reintegrate them back into trunk.
Sometimes I'll create a branch Y from another branch X, so I can start
with X's code. Normally I'll reintegrate Y into X first, then reintegrate X
into trunk.
Y --> X --> trunk
But what if I
free.fr> writes:
> A naive goal is to display the whole history of the 'myFolder/myFile' file,
> INCLUDING the number and message of the revision where the file has
> been deleted.
Agreed, this is a big hassle. I posted a similar complaint a while ago. My
suggestion was to add an option to "s
On Aug 16, 2010, at 10:27 AM, Ryan Schmidt wrote:
> On Aug 16, 2010, at 12:08, Jacob Weber wrote:
>
>> OS X doesn't support multiple files in the same directory with the same name
>> and different capitalization.
>
> Just to nitpick this point: of course Mac OS X s
If I change the capitalization of a directory name, it seems to cause problems
with merging. I'm using SVN 1.6.11 on Mac OS X. I'm not sure if this is
relevant, but OS X doesn't support multiple files in the same directory with
the same name and different capitalization. Can I report this as a b
Forgot to mention: I'm using SVN 1.6.11 client and 1.6.5 server.
Jacob
On May 22, 2010, at 7:31 PM, Jacob Weber wrote:
> Here's the situation: I just did a reintegrate from the HEAD of branch_X into
> trunk. I committed everything.
>
> At this point, the two branch
Here's the situation: I just did a reintegrate from the HEAD of branch_X into
trunk. I committed everything.
At this point, the two branches should be identical. Afterwards, I didn't
change either branch, except to commit the reintegrate itself to trunk, and to
commit a record-only merge to bra
Sometimes when I do a --reintegrate merge, I get some unexpected output, along
with the normal updates:
--- Merging differences between repository URLs into trunk-path
U /trunk-path/file1
U trunk-path/file2
trunk-path/file3
trunk-path/fil4
...
That is, I see a bun
Stein Somers:
> I see some self-refenertial mergeinfo in our /trunk, after lots of
> merges to and from. Maybe I explicitly added it with a record-only in
> some state of confusion. But it doesn't scare me at all. It would only
> matter if you explicitly merged /trunk to /trunk. And then, as far
Sperling wrote:
> On Thu, Feb 18, 2010 at 11:22:36AM -0500, Rob van Oostrum wrote:
>> On Thu, Feb 18, 2010 at 11:19 AM, Jacob Weber wrote:
>>> Do you mean that I don't need to delete my branch after a reintegrate, as
>>> suggested here:
>&
On Feb 18, 2010, at 7:37 AM, Mark Phippard wrote:
> On Thu, Feb 18, 2010 at 7:17 AM, Jacob Weber wrote:
>> Let's say I have a branch where I develop two features, X and Y. I then want
>> to merge only X back
>> into the trunk. I want to do some further development o
On Feb 18, 2010, at 8:00 AM, Rob van Oostrum wrote:
> On Thu, Feb 18, 2010 at 10:17 AM, Jacob Weber wrote:
> My concern is this:
> After we reintegrate from A into trunk, we'll need to revert A to trunk
> (according to my understanding of reintegrate merges.) So once we do
Let's say I have a branch where I develop two features, X and Y. I then want to
merge only X back into the trunk. I want to do some further development on Y,
and merge it into trunk later.
Is this possible with Subversion?
If I do a reintegrate into trunk, I could revert all the changes for Y,
I'm wondering if the following pattern will work:
- a branch A from trunk, where features are developed, before they're released
into trunk
- a branch AA from A, where more experimental features are developed, before
they're released into A, and then eventually into trunk. This way, while A's
f
20 matches
Mail list logo
