Hi,
Your query was titled as one about sparse checkouts and I didn't address
that. The process you describe doesn't match what I do and isn't
something I've tried. I'll let someone else jump in that might be able
to shed more light.
Subversion is a tool and, as with other tools, there are many ways to
use it - some more conventional than others. Ultimately, it is likely
more important to be consistent with the usage of your team. Perhaps
your colleagues will be in a better position to demonstrate that
consistency.
That said, here are some observations.
>> Thus my concern with the newly added items appearing in my feature
branch. When I commit, I don't want the log message with my ticket ID
attached to those new items. <<
The significant log message would normally be the one where the feature
branch is reintegrated with the trunk. Frequent sync merges from trunk
to the feature branch (during development of the feature) are
principally to avoid larger merges clashes for that final reintegration
process.
>> Probably why most the devs here don't seem to sync the trunk to
branch. <<
That seems unusual.
>> Trying to merge a group of changes is seen as unreliable. I'd guess
because changes to the trunk/release branch have never been sync'd down
to the feature branch. <<
Yep, the lack of sync merges may well be a factor.
My usage works for me but I accept that others may choose a different
path. Hopefully someone else will add their view too.
Regards.
On 23/01/17 17:46, Charles Wilt wrote:
>> It sounds like the changes have been merged but not committed. After you merged the trunk into the local working copy of the feature branch, did you then commit the changes back to the Subversion server?
>> The merge simply updates the local checkout of the working copy with the changes from the trunk. You should check that the merge did what you expect (it probably did), and run any tests that you normally would prior to any other change (perhaps just a test build or, perhaps, a full suite of unit tests). Once you are satisfied that all is well with the local copy, the changes need to be committed to the feature branch. It is then good practice to update the local working copy.
>>
> Thanks for the reply!
>
> I have not yet committed; I was waiting to get an answer to my question. :)
>
> Seeing the newly added files in trunk added to my feature branch freaked me out a bit. Perhaps further details of our environment is in order.
>
> Trunk contains what will become our next release. We also maintain a current release branch.
>
> All changes are made in a feature branch. Since there's 38,000+ files in our repository, sparse checkouts are the norm.
>
> I'm working with basically an entire ERP system written in RPGLE. Mostly monolithic code, so most bug fixes / enhancements effect a single program source (and the source(s) for it's screen UIs); so perhaps 3 or 4 linked source files maximum.
>
> Unless somebody happens to change the same program I am working with, changes made by others are highly unlikely to effect my branch.
>
> With this particular feature branch, I had checked out only a single file.
>
> Seeing the source files that had been added to the trunk by others appear in my feature branch made me worry about how things would look when I eventually re-integrate my branch into the trunk.
>
> I'm not sure exactly what/how the deployment team works. I know they do a full build of the trunk on our DEV & QA systems. But only changes are deployed to the production system. I believe they use the ticket ID in the log message to identity what objects are involved.
>
> Thus my concern with the newly added items appearing in my feature branch. When I commit, I don't want the log message with my ticket ID attached to those new items.
>
> Probably why most the devs here don't seem to sync the trunk to branch. Nor use the auto-merge. Instead they manually merge one item at a time from the branch back into the trunk. Trying to merge a group of changes is seen as unreliable. I'd guess because changes to the trunk/release branch have never been sync'd down to the feature branch.
>
> I've read the relevant sections of the svnbook and other documentation; but haven't quite managed take the simple examples and understand them in the context of our large team & project.
>
> Sorry for the book. Trying to provide all the info required to point out what I'm misunderstanding and/or doing wrong.
>
> ------------------------------------------------------
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3204206
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3204247
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2017-01-23 21:52:52 CET