Any chance the Roadmap can be updated since Q2 2014 has come and gone? I'm
sure there's been some functions completed, or nearly complete, even if
1.9.0 is not ready for production.
> On Jan 3, 2014, at 12:58 PM, Ben Reser wrote:
>
>> On 1/3/14, 8:59 AM, James Hanley wrote:
>> Can you expand on this - I am missing where the preceding differences would
>> be
>> an issue. From what I can see, if there is a delta, it is either the result
>
On Fri, Jan 3, 2014 at 12:35 AM, Ben Reser wrote:
> On 1/2/14, 7:16 PM, James Hanley wrote:
> > I've used the Rev keyword in some of our code, and we noticed that there
> may be
> > a use case gap for the Rev/Revision and possibly Id keyword.
> >
> > As expecte
I've used the Rev keyword in some of our code, and we noticed that there
may be a use case gap for the Rev/Revision and possibly Id keyword.
As expected the keyword gets updated with any checkin, but there may be a
need to have a merge-history aware version these keywords. Meaning that
the Rev sh
ie:
svn merge -cl merge_from_trunk https://svn.somerepo.com/project/trunk
#Any items merged in are added to change list "merge_from_trunk" to
# easily differentiate from local changes that the user does not want to
check in
svn status
M local_file_changes.txt
--- Changelist 'merge_from_tru
So other then tar-ing up the WC, there is no way to reproduce local changes
like this on another system? I know the example given is fairly simple,
but it could be very useful.
-Jim
On Tue, Aug 20, 2013 at 3:28 PM, Stefan Sperling wrote:
> On Tue, Aug 20, 2013 at 01:16:40PM -0400, Ja
This was with 1.8.1 client - BTW.
On Tue, Aug 20, 2013 at 1:16 PM, James Hanley wrote:
> Not sure if this is a valid operation, but should I be able to use svn
> merge, then svn diff to create a patch, then svn patch on another branch
> (or pristine checkout of the originating branch
Not sure if this is a valid operation, but should I be able to use svn
merge, then svn diff to create a patch, then svn patch on another branch
(or pristine checkout of the originating branch where the diff was created)
to create a replica of the merge operation?
The reason I ask is that it appear
fw/branches/int/my_project_03b
svn, version 1.8.0 (r1490375) compiled Jun 19 2013, 10:42:54 on
i686-pc-cygwin
On Tue, Jun 11, 2013 at 4:12 PM, James Hanley wrote:
> Is there any additional detail I can provide for this?
>
>
> On Thu, Jun 6, 2013 at 11:05 AM, James Hanley wrote:
>
>> S
Is there any additional detail I can provide for this?
On Thu, Jun 6, 2013 at 11:05 AM, James Hanley wrote:
> So, is there additional information I can provide - would doing a diff on
> the properties of MkImage show anything useful.. I couldn't see any myself
> but perhaps ther
So, is there additional information I can provide - would doing a diff on
the properties of MkImage show anything useful.. I couldn't see any myself
but perhaps there's some flags to get additional detail?
On Wed, Jun 5, 2013 at 5:00 PM, Andrew Reedick
wrote:
>
>
> &
kImage.exe
user_dude@computer_node ~/projects/my_project/my_project_03b_pristine
$
On Tue, Jun 4, 2013 at 3:28 PM, Andrew Reedick
wrote:
>
> > From: James Hanley [mailto:jhan...@dgtlrift.com]
> > Sent: Tuesday, June 04, 2013 3:12 PM
> > To: Andrew Reedick
> > Cc: users@
_user59528 May 30 19:28 MkSharedData.exe
...
2209 cm_user 85 May 07 12:52 run.cmd
user_dude@computer_node ~/projects/my_project/my_project_03b_pristine
$
On Tue, Jun 4, 2013 at 2:22 PM, Andrew Reedick
wrote:
>
>
> > From: James Hanley [mailto:jhan...@dgtlrift.com]
We are seeing a strange anomaly after our last check-in - on fresh checkout
there is a tree conflict into a new path - I've included the output below.
user_dude@computer_node~/projects/my_project
$ svn co https://svn.my_company.com/svn/my_project_fw/branches/int/
my_project_03b my_project_03b_pris
can you test if the reintegrate option is
removed completely from the script, how does it perform against 1.8 -
as I don't have a sandbox to test?
On Sun, Feb 24, 2013 at 9:19 AM, Stefan Sperling wrote:
> On Sun, Feb 24, 2013 at 07:57:14AM -0500, James Hanley wrote:
>> I guess I sho
)
On Feb 24, 2013, at 7:59 AM, Stefan Sperling wrote:
> On Sun, Feb 24, 2013 at 07:55:41AM -0500, James Hanley wrote:
>> Is this a use case that was taken into consideration, and will it be
>> "fixed" or the functionality/logic added to allow this use case?
>
> See
59 AM, Stefan Sperling wrote:
> On Sun, Feb 24, 2013 at 07:55:41AM -0500, James Hanley wrote:
>> Is this a use case that was taken into consideration, and will it be
>> "fixed" or the functionality/logic added to allow this use case?
>
> See my other reply for
I guess I should have read the next response in the thread before replying...
On Feb 24, 2013, at 7:52 AM, Stefan Sperling wrote:
> On Sun, Feb 24, 2013 at 12:14:04PM +, Andreas Tscharner wrote:
>>> So what is the proper way to continuously perform the workflow we're
>>> trying to do - that
Yes I have used git, etc - in the past, but we are forced to use svn
for the time being.
What I would like to quantify is if this shortcoming of subversion is
by design or if its a bug. From your description, it seems like the
former, and if so, what is the architectural reasoning?
I understand
at 7:22 PM, Matthew Pounsett wrote:
>
> On 2013/02/22, at 14:15, James Hanley wrote:
>
>> We are seeing merge tree conflicts where I believe svn is not working
>> as expected. I'm not entirely sure if this is due to a lack of
>> understanding for proper use on
We are seeing merge tree conflicts where I believe svn is not working
as expected. I'm not entirely sure if this is due to a lack of
understanding for proper use on our part, but it was my understanding
that reintegrate was to be used when pulling changes from a branch and
pushing them into the co
When creating a branch, it would be very useful if merge data could
optionally be included in svn status -u with the -g option.
Essentially, it would tell you if there are changes upstream from the
origination of the branch... I'm not entirely certain what the output
should look like, but it might
There's no interest/descending/rebuttal opinion to this? Should I
create a enhancement ticket? I thought that this was the medium to
first propose changes/enhancements for discussion.
On Mon, Apr 30, 2012 at 4:16 PM, James Hanley wrote:
> All,
>
> I'm raising the issue that
All,
I'm raising the issue that there should be an option to include merge
information of an "ls -v" in much the same way that "svn blame"
supports it. Although, I can easily use "svn blame -g" to find out who
/originally/ added a file, it's not intuitive, the more natural method
(IMHO) is to use
24 matches
Mail list logo
