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 Fri, Jan 3, 2014 at 12:35 AM, Ben Reser b...@reser.org 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 expected the keyword gets updated
On Jan 3, 2014, at 12:58 PM, Ben Reser b...@reser.org 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
of
direct modification
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
, 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 where the diff was
created)
to create a replica of the merge operation
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
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
This was with 1.8.1 client - BTW.
On Tue, Aug 20, 2013 at 1:16 PM, James Hanley jhan...@dgtlrift.com 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
/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 jhan...@dgtlrift.com wrote:
Is there any additional detail I can provide for this?
On Thu, Jun 6, 2013 at 11:05 AM, James Hanley jhan...@dgtlrift.comwrote:
So
: James Hanley [mailto:jhan...@dgtlrift.com]
Sent: Tuesday, June 04, 2013 1:44 PM
To: users@subversion.apache.org
Subject: Tree conflict on Fresh checkout
Amy_project_03b_pristine/Project/settings/MkSharedData.exe
C my_project_03b_pristine/Project/settings/MkImage
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
59528 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
andrew.reed...@cbeyond.netwrote:
From: James Hanley [mailto:jhan
...
For completeness sake, 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 s...@elego.de wrote:
On Sun, Feb 24, 2013 at 07:57:14AM -0500, James Hanley wrote:
I
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
I guess I should have read the next response in the thread before replying...
On Feb 24, 2013, at 7:52 AM, Stefan Sperling s...@elego.de 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
, Stefan Sperling s...@elego.de 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 more details, but yes, this is being
)
On Feb 24, 2013, at 7:59 AM, Stefan Sperling s...@elego.de 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 more details
:22 PM, Matthew Pounsett m...@conundrum.com 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 our part, but it was my
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 jhan...@dgtlrift.com wrote:
All,
I'm raising the issue
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 svn
20 matches
Mail list logo
