I think Ruby's point is right: we need to think about how a tool *feels* as you're using it. Making regular commits gives a nice rhythm to to working; in some ways it's nicer to just commit single files with C-x v v than to build complex changesets. (See gmane.c.v-c.arch.devel post 19 Nov, Tom Lord.) * Would like to generate an activity report, to e.g. mail to your boss or post to your blog. "What did I change today, across all these specified branches?" * It is possibly nice that tla by default forbids you from committing if emacs autosave or lock files exist -- I find it confusing to commit somethin other than what is shown in the editor window because there are unsaved changes. However, grumbling about unknown files is annoying, and requiring people to edit regexps in the id-tagging-method file to fix it is totally unreasonable. Perhaps there should be a preference to abort on unknown files, or perhaps it should be possible to specify forbidden files. Perhaps this is related to a mechanism to detect conflicted files: should refuse to commit if there are any .rej files lying around. *Those who lose history are doomed to recreate it.* -- broked (on #gnu.arch.users) *A universal convention supplies all of maintainability, clarity, consistency, and a foundation for good programming habits too. What it doesn't do is insist that you follow it against your will. That's Python!* -- Tim Peters on comp.lang.python, 2001-06-16 (Bazaar provides mechanism and convention, but it is up to you whether you wish to follow or enforce that convention.) ---- jblack asks for A way to subtract merges, so that you can see the work you've done to a branch since conception. ---- :: now that is a neat idea: advertise branches over zeroconf should make lca fun :-) ---- http://thedailywtf.com/ShowPost.aspx?PostID=24281 Source control is necessary and useful, but in a team of one (or even two) people the setup overhead isn't always worth it--especially if you're going to join source control in a month, and you don't want to have to migrate everything out of your existing (in my case, skunkworks) system before you can use it. At least that was my experience--I putzed with CVS a bit and knew other source control systems pretty well, but in the day-to-day it wasn't worth the bother (granted, I was a bit offended at having to wait to use the mainline source control, but that's another matter). I think Bazaar-NG will have such low setup overhead (just ``init``, ``add``) that it can be easily used for even tiny projects. The ability to merge previously-unrelated trees means they can fold their project in later. ---- From tridge: * cope without $EMAIL better * notes at start of .bzr.log: * you can delete this * or include it in bug reports * should you be able to remove things from the default ignore list? * headers at start of diff, giving some comments, perhaps dates * is diff against /dev/null really OK? I think so. * separate remove/delete commands? * detect files which were removed and now in 'missing' state * should we actually compare files for 'status', or check mtime and size; reading every file in the samba source tree can take a long time. without this, doing a status on a large tree can be very slow. but relying on mtime/size is a bit dangerous. people really do work on trees which take a large chunk of memory and which will not stay in memory * status up-to-date files: not 'U', and don't list without --all * if status does compare file text, then it should be quick when checking just a single file * wrapper for svn that every time run logs - command - all inputs - time it took - sufficient to replay everything - record all files * status crashes if a file is missing * option for -p1 level on diff, etc. perhaps * commit without message should start $EDITOR * don't duplicate all files on commit * start importing tridge-junkcode * perhaps need xdelta storage sooner rather than later, to handle very large file ---- The first operation most people do with a new version-control system is *not* making their own project, but rather getting a checkout of an existing project, building it, and possibly submitting a patch. So those operations should be *extremely* easy. ---- * Way to check that a branch is fully merged, and no longer needed: should mean all its changes have been integrated upstream, no uncommitted changes or rejects or unknown files. * Filter revisions by containing a particular word (as for log). Perhaps have key-value fields that might be used for e.g. line-of-development or bug nr? * List difference in the revisions on one branch vs another. * Perhaps use a partially-readable but still hopefully unique ID for revisions/inventories? * Preview what will happen in a merge before it is applied * When a changeset deletes a file, should have the option to just make it unknown/ignored. Perhaps this is best handled by an interactive merge. If the file is unchanged locally and deleted remotely, it will by default be deleted (but the user has the option to reject the delete, or to make it just unversioned, or to save a copy.) If it is modified locall then the user still needs to choose between those options but there is no default (or perhaps the default is to reject the delete.) * interactive commit, prompting whether each hunk should be sent (as for darcs) * Write up something about detection of unmodified files * Preview a merge so as to get some idea what will happen: * What revisions will be merged (log entries, etc) * What files will be affected? * Are those simple updates, or have they been updated locally as well. * Any renames or metadata clashes? * Show diffs or conflict markers. * Do the merge, but write into a second directory. * "Show me all changesets that touch this file" Can be done by walking back through all revisions, and filtering out those where the file-id either gets a new name or a new text. * Way to commit backdated revisions or pretend to be something by someone else, for the benefit of import tools; in general allow everything taken from the current environment to be overridden. * Cope well when trying to checkout or update over a flaky connection. Passive HTTP possibly helps with this: we can fetch all the file texts first, then the inventory, and can even retry interrupted connections. * Use readline for reading log messages, and store a history of previous commit messages! * Warn when adding huge files(?) - more than say 10MB? On the other hand, why not just cope? * Perhaps allow people to specify a revision-id, much as people have unique but human-assigned names for patches at the moment? ---- 20050218090900.GA2071@opteron.random Subject: Re: [darcs-users] Re: [BK] upgrade will be needed From: Andrea Arcangeli Newsgroups: gmane.linux.kernel Date: Fri, 18 Feb 2005 10:09:00 +0100 On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote: > small to medium sized ones). Last I checked, Arch was still too slow in > some areas, though that might have changed in recent months. Also, many IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the backend and a single file for the changesets and with sane parameters conventions miming SVN. The internal algorithms of arch seems the most advanced possible. It's just the interface and the fs backend that's so bad and doesn't compress in the backups either. SVN bsddb doesn't compress either by default, but at least the new fsfs compresses pretty well, not as good as CVS, but not as badly as bsddb and arch either. I may be completely wrong, so take the above just as a humble suggestion. darcs scares me a bit because it's in haskell, I don't believe very much in functional languages for compute intensive stuff, ram utilization skyrockets sometime (I wouldn't like to need >1G of ram to manage the tree). Other languages like python or perl are much slower than C/C++ too but at least ram utilization can be normally dominated to sane levels with them and they can be greatly optimized easily with C/C++ extensions of the performance critical parts. ----- * Fix up diffs for files without a trailing newline ----- * Directly import diffs! It seems a bit redundant to need to rescan the directory to work out what files diff added/deleted/changed when all the information is there in the diff in the first place. Getting the exact behaviour for added/deleted subdirectories etc might be hard. At the very least we could run diffstat over the diff, or perhaps read the status output from patch. Just knowing which files might be modified would be enough to guide the add and commit. Given this we might be able to import patches at 1/second or better. ---- When sending patches by email (optionall) send each one as a separate mail, with a sequence number [%03d/%03d] at the start of the Subject. See mail from linus 2005-04-07. http://linux.yyz.us/patch-format.html http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt ---- dwmw2 (2005-04-07) reorder patches by cherry-picking them from a main development tree before sending them on.