Sort by time | Sort by thread (beta)
Link to this comment:
Share to:
Loading...
- Your queue is empty. Add videos to your queue using this button:
or sign in to load a different list.
Loading...Saving...
Thanks, good advice!
But I found it found your audio comments a little bit out of sync with the video text which made it harder to listen...
derepiker 3 months ago
This has been flagged as spam show
2. You wouldn't create a directory /tags/v1 and copy /trunk to /tags/v1. If you try that you will get an error that the destination directory already exists. Rather, you just perform a copy operation with the source being /trunk and the destination being /tags/v1, were /tags/v1 is a directory that does not already exist.
rjollos 1 year ago
3. "You can also lock text file, but it's more important with binaries".
While this is a true statement, I think it is fairly well accepted that, "You can also lock text files, but this is generally note recommended".
rjollos 1 year ago
This has been flagged as spam show
4. " ... commit each file in a directory separately, instead of committing the entire directory in one commit action".
Each commit should encompass a single feature (which the speaker states elsewhere), so that you can apply or roll-back the feature by updating to a different revision. You wouldn't wan to separately commit each file in a set of files implementing a feature. Your commit has nothing to do with the number of files checked-in, but everything to do with the feature implemented.
rjollos 1 year ago
This has been flagged as spam show
5. I'd also argue that single file commits are not recommended if the single file contains multiple feature changes. I've found it most useful to have each commit encompass a single change. For example,
FIX: GUI slider bounds for Image page display control did not match bounds of model.
or:
CHG: Replaced edit box with a listbox so that we could enter and submit multiple entries in one operation.
Both changes could be in the same file, but you'd want to check them in separately.
rjollos 1 year ago
This has been flagged as spam show
6. Regarding "Blanket Changes": You can add as much detail as you want in the commit message, but if you are committing multiple features (blanket change), then you lose the ability to roll-back/apply that feature, which is very helpful in the course of debugging, or later removing changes that proved to be undesirable (as the author speaker later on). The emphasis should be on feature commits, not number of files associated with the commit.
rjollos 1 year ago
Comment removed
rjollos 1 year ago
Comment removed
rjollos 1 year ago
Comment removed
rjollos 1 year ago
Comment removed
rjollos 1 year ago
Comment removed
rjollos 1 year ago
Comment removed
rjollos 1 year ago
Comment removed
rjollos 1 year ago
A conflict CANNOT occur in the repo! It can only occur in your local copy. svn will not let you commit if one (or mroe) of the files is outof date, so you must update before a commit and hence deal with any conflicts in your local copy.
njrtoob 1 year ago
thanks, this was very helpful
starkhalo 2 years ago
Thanks for the tips.
CKewley 2 years ago