Release procedures
Hi, I must be doing something wrong or I'm expecting something I shouldn't: (1) I updated from the trunk (HEAD) (2) Fixed a couple of things (3) Commited to the trunk (4) Updated from RC_1_34 (over the same working folder) (5) Merged "merged_from_RC_1_34" and "HEAD" into working folder. For step 5 I'm using ToroiseCVS 1.8.26 using the merge dialog as follow: Start: merged_from_RC_1_34 End: HEAD After that I get lots of updated, and even conflicted, files, way beside those which are mine. Is that expected? I figured I would get only my files merged. If it is, is it OK to just commit my files and not the others? What about the tag? TIA Fernando Cacciola
Fernando Cacciola wrote:
Hi,
I must be doing something wrong or I'm expecting something I shouldn't:
(1) I updated from the trunk (HEAD) (2) Fixed a couple of things (3) Commited to the trunk (4) Updated from RC_1_34 (over the same working folder) (5) Merged "merged_from_RC_1_34" and "HEAD" into working folder.
For step 5 I'm using ToroiseCVS 1.8.26 using the merge dialog as follow:
Start: merged_from_RC_1_34 End: HEAD
After that I get lots of updated, and even conflicted, files, way beside those which are mine.
Is that expected? I figured I would get only my files merged.
It's only expected if you merge anything more that just your files.
If it is, is it OK to just commit my files and not the others?
I wouldn't risk it as errors in those other files might mask real problems in your code, or the interaction of your code with others, etc. I would suggest going back and doing the merge only with the files you changed.
What about the tag?
You only move the tag for the files you merged. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Fernando Cacciola wrote:
Hi,
I must be doing something wrong or I'm expecting something I shouldn't:
(1) I updated from the trunk (HEAD) (2) Fixed a couple of things (3) Commited to the trunk (4) Updated from RC_1_34 (over the same working folder) (5) Merged "merged_from_RC_1_34" and "HEAD" into working folder.
For step 5 I'm using ToroiseCVS 1.8.26 using the merge dialog as follow:
Start: merged_from_RC_1_34 End: HEAD
After that I get lots of updated, and even conflicted, files, way beside those which are mine.
Is that expected? I figured I would get only my files merged.
It's only expected if you merge anything more that just your files.
Hmmm, yes, of course, but I would have sweared I never had to merge only my files before. Maybe I was just lucky and did the changes in a moment no one else was doing it.
If it is, is it OK to just commit my files and not the others?
I wouldn't risk it as errors in those other files might mask real problems in your code, or the interaction of your code with others, etc.
I would suggest going back and doing the merge only with the files you changed.
Right, I screw up with the global merge so I'll just go back and do it again properly.
What about the tag?
You only move the tag for the files you merged.
OK. Btw, I usually use WinCVS, but I installed the latest version and I couldn't get it to use PLink (it looks for 'ssh' which I haven't). The "General" tabs in the Admin dialog box is missing, replaced by a notification that now you just have to set the environment variable CVSROOT. That's fine, but in that tab I used to define the ssh client, so I'm lost now. Now I used TortoiseCVS instead, but then, how do I get a list of all the files *I* changed (besides manually of course), anyone? Best Fernando Cacciola
It's likely that there is a mismatch of file formats. UNIX text files ends with a single \r character, while Windows ones ends with two: <CR><LF>. Make sure you use the UNIX format to check out the files (a CVS option), as it's probably the format of the files in the CVS repository. On 6/26/06, Fernando Cacciola <fernando_cacciola@hotmail.com> wrote:
Hi,
I must be doing something wrong or I'm expecting something I shouldn't:
(1) I updated from the trunk (HEAD) (2) Fixed a couple of things (3) Commited to the trunk (4) Updated from RC_1_34 (over the same working folder) (5) Merged "merged_from_RC_1_34" and "HEAD" into working folder.
For step 5 I'm using ToroiseCVS 1.8.26 using the merge dialog as follow:
Start: merged_from_RC_1_34 End: HEAD
After that I get lots of updated, and even conflicted, files, way beside those which are mine.
Is that expected? I figured I would get only my files merged.
If it is, is it OK to just commit my files and not the others?
What about the tag?
TIA
Fernando Cacciola
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It's likely that there is a mismatch of file formats. UNIX text files ends with a single \r character, while Windows ones ends with two: <CR><LF>.
I think on UNIX it's a single \n. The only OS using \r as "new line" is Mac iirc. But you are right about windows using \r\n. Philippe
Gregory Dai wrote:
It's likely that there is a mismatch of file formats. UNIX text files ends with a single \r character, while Windows ones ends with two: <CR><LF>.
It's not that... on my second try I checked out the HEAD from scratch since my fixes were already in.. I just need to merged them into the release branch. (I would have that problem in every file if this were the cause) Fernando Cacciola
"Fernando Cacciola" <fernando_cacciola@hotmail.com> wrote in message news:e7plic$9b9$1@sea.gmane.org...
Hi,
I must be doing something wrong or I'm expecting something I shouldn't:
(1) I updated from the trunk (HEAD) (2) Fixed a couple of things (3) Commited to the trunk (4) Updated from RC_1_34 (over the same working folder) (5) Merged "merged_from_RC_1_34" and "HEAD" into working folder.
For step 5 I'm using ToroiseCVS 1.8.26 using the merge dialog as follow:
Start: merged_from_RC_1_34 End: HEAD
The code seems to be in the CVS. You've got one minor documentation typo. Over the free function get_optional_value_or you have a comment that says "Returns a pointer to the value if this is initialized, otherwise, returns NULL." This is incorrect. The entire point of this function is to give defined behavior by returning a default value when the optional is uninitialized. Joe Gottman
Joe Gottman wrote:
"Fernando Cacciola" <fernando_cacciola@hotmail.com> wrote in message news:e7plic$9b9$1@sea.gmane.org...
Hi,
I must be doing something wrong or I'm expecting something I shouldn't:
(1) I updated from the trunk (HEAD) (2) Fixed a couple of things (3) Commited to the trunk (4) Updated from RC_1_34 (over the same working folder) (5) Merged "merged_from_RC_1_34" and "HEAD" into working folder.
For step 5 I'm using ToroiseCVS 1.8.26 using the merge dialog as follow:
Start: merged_from_RC_1_34 End: HEAD
The code seems to be in the CVS.
You mean the trunk right? Indeed. I just need to merge it into the release branch.
You've got one minor documentation typo. Over the free function get_optional_value_or you have a comment that says "Returns a pointer to the value if this is initialized, otherwise, returns NULL." This is incorrect. The entire point of this function is to give defined behavior by returning a default value when the optional is uninitialized.
Oops, of course.. bad copy/paste ;) Thank you for spotting it! Fernando Cacciola
Fernando Cacciola wrote:
Hi,
I must be doing something wrong or I'm expecting something I shouldn't:
(1) I updated from the trunk (HEAD) (2) Fixed a couple of things (3) Commited to the trunk (4) Updated from RC_1_34 (over the same working folder)
Should be RC_1_34_0.
(5) Merged "merged_from_RC_1_34" and "HEAD" into working folder.
Should be merged_to_RC_1_34_0.
For step 5 I'm using ToroiseCVS 1.8.26 using the merge dialog as follow:
Start: merged_from_RC_1_34 End: HEAD
After that I get lots of updated, and even conflicted, files, way beside those which are mine.
Is that expected? I figured I would get only my files merged.
If it is, is it OK to just commit my files and not the others?
What about the tag?
I've never used TortoiseCVS, so I don't know. I use cvs and follow the release procedures described at http://boost.org/more/release_procedures.htm. I never merge more than the files I'm working on. Don't forget to "cvs tag" when you're done merging your changed into RC_1_34_0. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> writes:
I've never used TortoiseCVS, so I don't know. I use cvs and follow the release procedures described at http://boost.org/more/release_procedures.htm. I never merge more than the files I'm working on.
I just want to reiterate something I've said here before. I've seen it repeatedly: people who pick up a GUI frontend for CVS (or for most any other command-line tool) assuming it will make the tool easier to understand often end up with an incomplete or erroneous understanding of the tool, and they end up making crucial mistakes. There are lots of ways to explain this phenomenon: for one thing, the definitive documentation of the tool is always written for the command-line, and the GUI's documentation, in the interesting cases, usually refers to it. For another thing, the GUI's abstractions are almost invariably incomplete. At some level, the GUI always exposes the underlying tool, so you have to learn it anyway. And that doesn't even account for the reliability problems that one normally sees in such frontends. The problem IMO is that command-line tools essentially have untyped interfaces. There's usually some relatively clean description of what inputs they accept, but their outputs, which usually occur as text in two output streams, are much less well-defined, particularly in the case of "error conditions." When something goes wrong, the GUI often can't recognize it, or can't report it, or can't report it in terms of the GUI's abstractions. IMO this is one of the reasons that Linux has such a hard time approaching real joe-nonhacker-friendliness. The answer, of course, is to have the command-line tools and the GUIs use libraries with strongly-typed interfaces and well-defined exceptions. But who has time for that? :) So, moral of the story: especially in cases where what you do with the tool is going to affect other people (e.g. Boost), learn the underlying command-line tool first. Then if the GUI makes some things easier, feel free to use it, with the full understanding of what's really happening under the covers. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Eric Niebler" <eric@boost-consulting.com> writes:
I've never used TortoiseCVS, so I don't know. I use cvs and follow the release procedures described at http://boost.org/more/release_procedures.htm. I never merge more than the files I'm working on.
I just want to reiterate something I've said here before. I've seen it repeatedly: people who pick up a GUI frontend for CVS (or for most any other command-line tool) assuming it will make the tool easier to understand often end up with an incomplete or erroneous understanding of the tool, and they end up making crucial mistakes.
You are absolutely right and FWIW I followed your advice from the first time I read it.. only not to sufficient extent. This particular case seems to illustrate your point very well: I kept using GUI frontends but I started to make sure I understand the command line issued by the GUI. In the tortoiseCVS case I always check that the command line is correct before entering my password. The version of TortoiseCVS I was using initially had room for just one entry in the merge dialog; but since I always check the cmdline I could see that -jHEAD was missing so I aborted. Then I installed a latest TortoiseCVS which has a more complete merge dialog allowing you to specify two merge points. But still I made a mistake: a GUI frontend keeps track of the files that changes and you never need to care for that yourself. In cvs cmdline you don't neccessarily need to enumerate target files. Thus, whenever I read something like "cvs update -jABC -jDEF foo.c" in a tutorial/guidelines, I sort of ignore the "foo.c" part, believing that I may not need to pass it in an actual case. That's sometimes right, but you better understand what happens when you don't specify any files! I realize now that using a GUI, that is, never thinking about the actual target files that go into the cmdline, made me misunderstood the behavior when those are missing. (exactly as you said, got me into misunderstanding how cvs really works). I noticed that the cmdline was not exactly as instructed because no files were listed but I figured it would just work anyway. Fernando Cacciola
On 6/27/06 12:40 PM, "David Abrahams" <dave@boost-consulting.com> wrote: [SNIP] [GUI programs of CLI tools act wonky in passing information either way between the GUI and CLI layers because of problems in model mismatch or screen scraping....]
IMO this is one of the reasons that Linux has such a hard time approaching real joe-nonhacker-friendliness. The answer, of course, is to have the command-line tools and the GUIs use libraries with strongly-typed interfaces and well-defined exceptions. But who has time for that? :) [TRUNCATE]
The Subversion SCM system is modeled like this, at least the library interface part. (I don't know if it uses exceptions.) The CLI version of the SVN client simply calls the SVN libraries. If a GUI program decides to screen-scrape the CLI tool instead of using the libraries, it's probably doing something wrong. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew@hotmail.com> writes:
On 6/27/06 12:40 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
[SNIP]
[GUI programs of CLI tools act wonky in passing information either way between the GUI and CLI layers because of problems in model mismatch or screen scraping....]
IMO this is one of the reasons that Linux has such a hard time approaching real joe-nonhacker-friendliness. The answer, of course, is to have the command-line tools and the GUIs use libraries with strongly-typed interfaces and well-defined exceptions. But who has time for that? :) [TRUNCATE]
The Subversion SCM system is modeled like this, at least the library interface part. (I don't know if it uses exceptions.) The CLI version of the SVN client simply calls the SVN libraries.
Which CLI version of the SVN client? There are lots ;-)
If a GUI program decides to screen-scrape the CLI tool instead of using the libraries, it's probably doing something wrong.
Agreed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 7/9/06 1:36 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
Daryle Walker <darylew@hotmail.com> writes: [SNIP]
The Subversion SCM system is modeled like this, at least the library interface part. (I don't know if it uses exceptions.) The CLI version of the SVN client simply calls the SVN libraries.
Which CLI version of the SVN client? There are lots ;-)
I didn't realize that. I was talking about the official CLI client (and libraries) at <http://subversion.tigris.org>.
If a GUI program decides to screen-scrape the CLI tool instead of using the libraries, it's probably doing something wrong.
Agreed.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew@hotmail.com> writes:
On 7/9/06 1:36 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
Daryle Walker <darylew@hotmail.com> writes: [SNIP]
The Subversion SCM system is modeled like this, at least the library interface part. (I don't know if it uses exceptions.) The CLI version of the SVN client simply calls the SVN libraries.
Which CLI version of the SVN client? There are lots ;-)
I didn't realize that. I was talking about the official CLI client (and libraries) at <http://subversion.tigris.org>.
Sorry, I saw CLI and thought it said GUI. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (8)
-
Daryle Walker -
David Abrahams -
Eric Niebler -
Fernando Cacciola -
Gregory Dai -
Joe Gottman -
Philippe Vaucher -
Rene Rivera