Message board for the users of flat assembler.
> Heap > version management & team work
even alone, manage the differents (consecutive/fork) versions of any project is pretty hard and confusing.
take as an example, the case you work alone on a "huge" project, say it is composed by many files.
you will have the original on a machine, say M01.
and you copy it to an amovible drive, say D01.
you put D01 in the machine M02, and modify the sources directlly in D01.
you copy the content in M02, and continue to work on M02.
you put D01 in the machine M03, and so on...
then, you continue to work on the code on M01, while you work also on the code on M02, D01, M03, D02, etc...
what is anoying then, whatever version management tool you use, is the update and commit phase.
you will always have to manage conflicts.
then, what to do?
personnaly, for my own projects, i prefer let my brain use a detailled whatsnew file, and compare just the whatsnew, then, merge manually the changes (copy/paste), and update the whatsnew.
my own conclusion is that a project with many working copies everywhere is a cure to update, and using a sort of "automated" tool to do the job is like using a sextoy to fecundate our wives.
better is to use good communication of what was done, and update the changes manually.
remember that the long task in coding is not to copy paste code, but to write and test it line by line. ones the code is ok, copy paste is a neggligible task.
and ones you have a pretty good and complete version, you can commit to svn/git/etc... to broadcast to the community.
before, use communication, send by mail, or anything else, to the more responsible coder (like linus does when he compiles and validate a linux kernel), this person will then commit to the version management tool.
but as long as the IT evolve, the tendency is to give the job to pretty uncompetent people that will commit not working code...( like me) and be annoyed by the old (2 month ago) crappy code commited. then, remember to backup your work, outside the version manager, somewhere on some drives. and manage them by hand.
and don't forget to backup, and multiply the copies on many different storages.
|11 Sep 2012, 19:41||
If I work on different drives - I use a simple DIFF. tool to compare directores - just to see the changes I made or forgot to make.
It is not a merging tool, just a tool for seeing the differences.
But for a team of ASM coders - yeah, that would be not enough, I imagine.
|11 Sep 2012, 21:06||
I like distributed version control systems. It is really better than the centralized systems. At least you have full backup on every machine cloned the repository.
The VCS can save you a mass of time. IMHO, every programmer must learn at least one good VCS and use it all the time. Because this way he will be able to create his projects faster and better.
And IMO, by the ideology reasons, for assembly programmer, the best choice is "fossil" DVCS, because it is very small, light and minimalistic.
If someone think VCS is big and clumsy environment with clients, servers, setup and administration - he must try fossil.
|12 Sep 2012, 04:44||
I like distributed version control systems. It is really better than the centralized systems....
I second JohnFound's endorsement of "fossil". It's very robust, small and capable -- I use it for all my projects.
|12 Sep 2012, 07:18||
My method is to assign a special plaintext file as the central info resource
Every-single-time I did anything to the source - deletion, addition, change - I document what I did on which file(s), and when, and on which drive / machine / location
And that plaintext file I keep it on my thumbdrive, which I take with me everywhere I go
That way I have a central resource to fall back on
But of course, I backup everything
|12 Sep 2012, 10:02||
edfed, for responsible VCS, you don't push non-working code to the main repository. For non-distributed systems like subversion, this simply means you don't commit non-working code. (Of course there's exceptions when doing initial project setup/scaffolding, or working on larger feature branches, but at the very least you don't push stuff that doesn't build, or breaks functionality for people not working on the same feature as you).
For decentralized VCS, you generally make feature branches for every little feature, since they're so inexpensive and don't affect anybody else. You do multiple commits (possibly even non-working code!) to your local repository, with commit message detailing what the changes are (and there goes the need for maintaining a stupid separate .txt file with changes). You now have the ability to do a lot of code experimentation without having to revert to older versions from clumsy backups, you have superior diffing capabilities, et cetera. And if you need to work on a different feature before completing the one you're currently working on (critical bugfix necessary, management reassigning priorities, ...) it's a very easy thing to do.
Once a feature is complete, you squash all your local feature-branch commits into a single commit back to the mainline (thus not polluting the global history with your, possibly many and experimenting, local commits), and then you either push changes to the central project repository (the "we've just moved to DVCS and are still learning" or "we have extremely competent developers" approach), or you issue a pull request to the responsible project maintainer, who will then evaluate your changes and hopefully merge them into the central repo.
Oh, and because of it's decentralized nature, it's possible for multiple developers to work on the same feature, without going through the central repository, and without resorting to stupid methods like email, instant-messaging file transfer, and the like.
It's a much, much better way to work than any of the archaic manual methods that have been proposed so far in this thread... but it's not a magic silver bullet, and you still need to communicate with your fellow developers.
(Oh, and while proper (D)VCS is absolutely necessary in a team situation, I wouldn't do without it on anything beyond toy projects even when doing single-developer work. It's just too valuable having a decent searchable and diffable history of your source code.)
|12 Sep 2012, 11:02||
< Last Thread | Next Thread >
Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.
Website powered by rwasa.