Hi All
We have a revision that contains a few changed files on the trunk:
r345
/usr/ext/a.java
/usr/ext/b.java
We like to merge this a branch working copy.
Can we perform multiple merge svn with the same revision number ?
We have a reason to do that; We know it doesnt make sense in this simple
ex
No suggestions at all?
--
Remo Del Bello
On Apr 9, 2013, at 3:14 PM, Remo Del Bello wrote:
> I have setup a repository location on our Apache server at '/repos' with the
> following:
>
>
> DAV svn
> SVNParentPath /path/to/repos
> SVNListParentPath on
>
> I did this so tha
Bert Huijben writes:
> And both merge and patch allow adding directories with files inside...
You can certainly add any such files to the changelist but using the
changelist to commit is a problem since the commit doesn't include the
directory.
Changelist support for directories would be one so
On Wed, 2013-04-17 at 11:42 -0700, BRM wrote:
> I'd suggest a slight modification to your process if you can - that
> is:
>
> 1. Checkout a new working copy
> 2. Apply the patch to the new working copy
> 3. Review
> 4. Delete the new working copy
>
> Now I realize in some cases that may not be a
On 17.04.2013 16:23, Nick wrote:
> Am I missing something for this workflow? Is there a simpler way?
Apart from using a new working copy for each review, there is currently
no simpler way.
We're in the very, very early stages of designing a new feature
(tentatively named "checkpoints") that woul
I'd suggest a slight modification to your process if you can - that is:
1. Checkout a new working copy
2. Apply the patch to the new working copy
3. Review
4. Delete the new working copy
Now I realize in some cases that may not be an option - too large a down, etc.
If the patch provider is using
On 04/17/2013 11:32 AM, Philip Martin wrote:
> "C. Michael Pilato" writes:
>
>> On 04/17/2013 09:43 AM, Philip Martin wrote:
>>> The behaviour looks simple to define for 'patch' and 'merge', I was
>>> thinking about 'svn add --force' which marks all the unversioned files
>>> for addition.
>>
>> Y
And both merge and patch allow adding directories with files inside...
And I have no idea how we can perform merge tracking on a merge
filtered by a change list... Merge the tree for each of the selected
files and ignore all the restructuring changes (adds/deletes)?
Bert From: Philip Martin
Sent
Philip Martin writes:
> "C. Michael Pilato" writes:
>
>> 'svn merge' comes to mind as one that, like patch, does not always have
>> explicitly named targets.
>
> Yes, merge is another candidate for this behaviour.
I think it's a reasonable suggestion for patch/merge at least, so I've
raised:
h
"C. Michael Pilato" writes:
> On 04/17/2013 09:43 AM, Philip Martin wrote:
>> The behaviour looks simple to define for 'patch' and 'merge', I was
>> thinking about 'svn add --force' which marks all the unversioned files
>> for addition.
>
> You mean, perhaps, 'svn add --force -R' (or some other n
On 04/17/2013 09:43 AM, Philip Martin wrote:
> The behaviour looks simple to define for 'patch' and 'merge', I was
> thinking about 'svn add --force' which marks all the unversioned files
> for addition.
You mean, perhaps, 'svn add --force -R' (or some other non-empty depth).
But that marks files
On Wed, 2013-04-17 at 11:43 +0100, Philip Martin wrote:
> > The 'patch' subcommand does not seem to support applying a
> changelist
> > description to the files that are part of the patch. Any plans to
> > support this?
> >
> > (Should I be asking this on the dev list?)
>
> That sounds like a use
"C. Michael Pilato" writes:
> On 04/17/2013 06:43 AM, Philip Martin wrote:
>> [dev CC'd]
>>
>> Nick writes:
>>
>>> The 'patch' subcommand does not seem to support applying a changelist
>>> description to the files that are part of the patch. Any plans to
>>> support this?
>>>
>>> (Should I be
On 04/17/2013 06:43 AM, Philip Martin wrote:
> [dev CC'd]
>
> Nick writes:
>
>> The 'patch' subcommand does not seem to support applying a changelist
>> description to the files that are part of the patch. Any plans to
>> support this?
>>
>> (Should I be asking this on the dev list?)
>
> That
If you're not opposed to using (if only as a shim layer) the C programming
language, may I (and presumably "we", with Daniel in mind) suggest that you
use Subversion's existing parser API (svn_repos_parse_dumpstream2) and
simply supply your own customized parser callback function vtable?
On 04/16/
[dev CC'd]
Nick writes:
> The 'patch' subcommand does not seem to support applying a changelist
> description to the files that are part of the patch. Any plans to
> support this?
>
> (Should I be asking this on the dev list?)
That sounds like a useful feauture. The list of files affected by
someone, any ide pls?
thanks
On Tuesday, March 19, 2013 11:41:19 AM UTC+1, Cicik wrote:
>
> Hi,
> in my company we are using TortoiseSVN with automatic merges turned off
> this way( http://tortoisesvn.tigris.org/faq.html#noautomerge ). But when
> I am merging range of revision(feature branch), T
17 matches
Mail list logo
