Sean (Jun 09 2018 at 18:32): Sean (Jun 09 2018 at 18:32):@Cezar you now have commit rights to the repository.
Sean (Jun 09 2018 at 18:34):Thank you for all your efforts thus far. With this access, you are formally welcomed to the development team with all the rights and responsibilities that are entailed. Please (re-)read the section in the HACKING file about commit rights.
The gist is to do your best, leave things better than you found them, and help fix anything you break. ;)
Sean (Jun 09 2018 at 18:36):@Saran Narayan you now have commit rights to the repository.
You've done a great job working with your mentor on patch iterations and it'll be great to see that process streamlined now that you can work incrementally directly on the code you're working with.
As I said, please read the HACKING file section about developers with commit rights, particularly your responsibilities and expectations.
Saran Narayan (Jun 09 2018 at 18:41):wow thank you :)
will read the commit rights section in HACKING file.
Sean (Jun 09 2018 at 18:42):thank you for all you've done. you've earned it, so keep up the good work.
Sean (Jun 09 2018 at 18:43):don't hesitate to ask if you have any questions
Sean (Jun 09 2018 at 18:49):@Saran Narayan and @Cezar please perform a simple test commit to the repository, to make sure I've set up everything on my end and you're good to go on your end
Sean (Jun 09 2018 at 18:50):clean up a comment, fix a typo, indent a file, etc ... some improvement and try to commit
Saran Narayan (Jun 09 2018 at 18:52):hmm okay will find something small to fix
Saran Narayan (Jun 09 2018 at 19:05):okay I am gonna fix my name in authors file, is that fine?
Sean (Jun 09 2018 at 19:06):ah, yes please!
sorry about that. I see the mistake now.
Saran Narayan (Jun 09 2018 at 19:11):It worked yay!
Sean (Jun 09 2018 at 19:11):woot, that worked :)
Sean (Jun 09 2018 at 19:12):so once you read hacking, you should be good to go
Sean (Jun 09 2018 at 19:13):you cannot commit too frequently, so don't worry about committing 200 times a day if you're so inclined. just make sure your commits make sense, don't knowingly break things, and that you have good commit messages that say what the code change does not (like why or summarizing points)
Saran Narayan (Jun 09 2018 at 19:17):getting that "With great powers, comes great responsibility" vibe..
have good commit messages that say what the code change does not (like why or summarizing points)
you said "not (like why or summarizing points)". So the commit messages must be short?
Cezar (Jun 09 2018 at 19:45):@Saran Narayan and @Cezar please perform a simple test commit to the repository, to make sure I've set up everything on my end and you're good to go on your end
done, it works
Sean (Jun 09 2018 at 19:50):excellent @Cezar ... note that is a user-visible change given you measured performance and observed a significant improvement (10%) that we can likely expect to see broadly -- that means you can add a line to the NEWS file as well.
Cezar (Jun 09 2018 at 19:51):i've also started reading HACKING again. i'm wondering if sh/indent.sh is made obsolete by sh/ws.sh? or does indent make some other changes?
Cezar (Jun 09 2018 at 19:52):i'll edit NEWS as well, but i'll try to do so via ssh
Cezar (Jun 09 2018 at 19:52):i tried checking out via ssh a few days ago and got some errors
Cezar (Jun 09 2018 at 19:56):ok, it's checking out now. that should make committing easier. i'm also curious about code reviews from now on. do i create a ticket and then commit myself when everything is fine, or do i just commit my changes and if any problem arises, fix on top of that?
Sean (Jun 09 2018 at 20:13):those scripts do slightly different things and are soon to be out-of-date so I wouldn't worry about it too much
Sean (Jun 09 2018 at 20:16):ok, it's checking out now. that should make committing easier. i'm also curious about code reviews from now on. do i create a ticket and then commit myself when everything is fine, or do i just commit my changes and if any problem arises, fix on top of that?
the latter! no more tickets. you're entrusted as part of the team now, and we're set up reactive instead of preventive. that means committing and reacting to feedback is expected.
Cezar (Jun 09 2018 at 20:20):ok, i updated NEWS as well, and committing via ssh works properly here
Sean (Jul 16 2018 at 14:08):@Shubham Rathore you now have direct commit access to the repository. Please test commit to the repository to make sure everything is set up correctly and feel free to commit at will (frequently). ;)
Sean (Jul 16 2018 at 14:09):you can read the section in the top-level HACKING file if you have any doubts about what you can/cannot do, or ask if needed, but thank you for all your work thus far!
Shubham Rathore (Jul 16 2018 at 18:46):Thanks @Sean . But I'm unable to commit! "authorization error E170001 " .
Sean (Jul 16 2018 at 19:03):@Shubham Rathore what is your checkout?
Sean (Jul 16 2018 at 19:05):you (obviously?) need to supply your sf username and password either on first commit or on checkout, depending on whether you have an https or svn+ssh checkout
Sean (Jul 16 2018 at 19:05):if you don't have one of those two, you will need to get a new checkout
Shubham Rathore (Jul 16 2018 at 19:28):Yup, I've got neither of the two, I'll have to checkout again
Shubham Rathore (Jul 16 2018 at 20:11):No offenses, but git is better :P
Sean (Jul 16 2018 at 23:41):No offenses, but git is better :P
no offense taken, I use both :)
Sean (Jul 16 2018 at 23:47):nearly identical in basic usage. svn is actually fewer steps and simpler in many respects (e.g., a svn commit == git commit+push)
Sean (Jul 16 2018 at 23:55):@Shubham Rathore this may help, shows what the git commands are in svn
Sean (Jul 16 2018 at 23:55):https://git-scm.com/course/svn.html
Sean (Jul 16 2018 at 23:56):or more concisely: https://www.perforce.com/blog/list-of-equivalent-commands-in-git-mercurial-and-svn
Shubham Rathore (Jul 17 2018 at 07:57):nearly identical in basic usage. svn is actually fewer steps and simpler in many respects (e.g., a svn commit == git commit+push)
True dat ! Best part .
Cezar (Jul 17 2018 at 12:50):i think git is faster when doing things like log, and doesn't require an internet connection (committing some changes also doesn't require internet). i know the reason, but the end result is still this. i think the speeds when checking out code are also faster, but i might've got the wrong impression or might be sourceforge's fault
Cezar (Jul 17 2018 at 12:52):svn doesn't seem to have something like git add -i, and i think it's useful when making unrelated changes to the same file, or if you want to exclude some whitespace changes in a commit
Daniel Rossberg (Jul 18 2018 at 17:24):No offenses, but git is better :P
No offenses, but svn is better ;)
The big issue with git is that you have to take care for at least two databases: The local one on your computer and a distant one on a server (supposing you want to contribute to someones project or publish your own stuff). This isn't trivial. When @Cezar writes that 'log' is faster then he could made a mistake here, because he looked only at his private database but not at the one on the server (which could have new commits). There are pros and cons of database duplication.
And what disqualifies git entirely is that there is no good GUI for it.
Cezar (Jul 18 2018 at 22:33):The big issue with git is that you have to take care for at least two databases
i'm not familiar with the problem here. i don't really think you take care of two databases. the contributor gets the source, makes his changes, sends them upstream somehow (in the case of github, via pull requests, but there are other mechanisms). the maintainer merges the changes and solves conflicts, if they arise. i'm not seeing how someone has to take care of many databases. i suppose you have to fetch changes from upstream, but it's the same with svn
And what disqualifies git entirely is that there is no good GUI for it.
fair point. do you mean tortoise svn? i don't have experience with git guis, but have you looked at git-tower?
Daniel Rossberg (Jul 19 2018 at 17:01):The big issue with git is that you have to take care for at least two databases
i'm not familiar with the problem here. i don't really think you take care of two databases. the contributor gets the source, makes his changes, sends them upstream somehow (in the case of github, via pull requests, but there are other mechanisms). the maintainer merges the changes and solves conflicts, if they arise. i'm not seeing how someone has to take care of many databases. i suppose you have to fetch changes from upstream, but it's the same with svn
Cloning a git repository means to copy its database. I.e., if you clone a git repository from (e.g.) github on your PC at home you copy its database to your computer. This enables you to view the history, make commits, etc. offline. I.e., at least two databases: The projects repository at the internet and the one on your computer.
And, you have to know that you must push the changes to the projects git repository to publish them. A green status in git means that all changes are committed locally, but the system itself doesn't remind you to publish your changes to the projects main repository.
On the other hand in subversion, you have to commit your changes to the server to get the green status, i.e. the system insists in publishing them. It's a client-server-system: The repository is hosted on a server in the internet and you have only a client program on your computer. For every real action (getting the history, commit changes, etc.) it has to contact the server. But the system can remind you if you get out of sync.
As I said, there are pros and cons.
And what disqualifies git entirely is that there is no good GUI for it.
fair point. do you mean tortoise svn? i don't have experience with git guis, but have you looked at git-tower?
Not necessarily TortoiseSVN (which is good), the old integration in KDE was good too. The git integration in KDE is very rudimentary, and TortoiseGIT can't be installed as easily as TortoiseSVN and you need to be a git expert to know what the menu options really mean.
Git Tower seems to be closed source.
Shubham Rathore (Jul 20 2018 at 03:36):No offenses, but git is better :P
No offenses, but svn is better ;)
The big issue with git is that you have to take care for at least two databases: The local one on your computer and a distant one on a server (supposing you want to contribute to someones project or publish your own stuff).
Working on two databases ensures that there is no single point of failure. Everyone has a backup of the project data. Imagine the svn server suffering from a kind of corruption and the last backup was quite a time ago. It'll take a lot of time to get the project timeline back on track.
Sean (Jul 22 2018 at 02:52):svn doesn't seem to have something like
git add -i, and i think it's useful when making unrelated changes to the same file, or if you want to exclude some whitespace changes in a commit
It doesn't have interactive staging because there's no need to stage. In a way, it avoids that step as a matter of efficiency, limitation, principle, or whatever perspective one chooses to value.
Sean (Jul 22 2018 at 02:54):Logging taking longer is entirely a function of having the repo live on a remote server. If the server is local, there isn't a difference. Remote git cloning is typically no faster or slower (at least not in a significant way) than svn.
Cezar (Jul 22 2018 at 20:33):Logging taking longer is entirely a function of having the repo live on a remote server. If the server is local, there isn't a difference. Remote git cloning is typically no faster or slower (at least not in a significant way) than svn.
i do understand the reason, but it doesn't change the end result (slower operations when needing to reach the server)
Cezar (Jul 22 2018 at 20:35):i suppose i still don't understand why git's model is problematic. i understand how they're different, but i don't see why one is better than the other
Sean (Jul 23 2018 at 17:37):i suppose i still don't understand why git's model is problematic. i understand how they're different, but i don't see why one is better than the other
Both can be problematic or no problem whatsoever. It depends on many factors including how many developers, what kind of development workflows are in place, how software assurance is asserted in the project, whether that's even something the developer(s) think about, whether there's social interaction among developers, how frequent they interact, ...
Sean (Jul 23 2018 at 17:46):there are clear cases where git (or more specifically distributed VCS or a VCS with offline commit capability) is superior -- e.g., if a team's developers are frequently disconnected from the internet, you really want offline commit or fast local branching (or both). if you don't have a team and are coding by yourself, it's also clearly superior to have all the repo right at your fingertips (but then I would have put the server at my fingertips even in a centralized VCS, so it's moot performance-wise).
Sean (Jul 23 2018 at 17:46):the differences and considerations grow as you introduce interactions and developers
Sean (Jul 23 2018 at 17:47):if nothing is done until it's pushed to a central repository, then is should be obvious how a centralized vcs would be more efficient at doing this
Sean (Jul 23 2018 at 17:48):if that change must be communicated to a team of others so that everyone knows what is going on, then you really want commits to be small and succinct -- as readable and quickly reviewable as possible
Sean (Jul 23 2018 at 17:50):communicating to a team in the 5-25 range, DVCS can be incredibly harmful as the local commit capability tends to lead towards larger feature-based changes (e.g., GitFlow model) that are typically no longer reviewed at a source code level. they also tend to come in much bigger dumps, also practically impossible to review unless you have 100's of developers and/or that's your full time job (e.g., the Linux kernel model)
Last updated: Jan 09 2025 at 00:46 UTC