[darcs-users] Re: Darcs idioms

Eric S. Johansson esj at harvee.org
Sun Jun 6 03:17:31 UTC 2004


Samuel A. Falvo II wrote:

> On Friday 04 June 2004 04:00 am, Eric S. Johansson wrote:
> 
>>another tool I will be constructing is a "publish repository" tool. 
>>Again, something that should not require a lot of hand use but does.
> 
> 
> What do you mean by this?

I should be able to say "publish this repository" and the able to extract from the context where I want a copy of the current repository to go and how it should get there.  Currently, I need to type a bunch of commands that make my hands hurt in order to get data to the repository.

I can fake somewhat using the same trick I did with my sandbox code by using the next up directory level as the context specifier.  I'll probably just use rsync and push my data to a local directory which is Web accessible.  And NO, the link technique isn't sufficient because I do not wish to make my mistakes instantly visible worldwide.   


> Most such "releases" are source releases anyway.  The only things that 
> ought to have proper execute permissions are support scripts like 
> "depend.sh", which is usually invoked as part of the normal operation of 
> make.

you are making way too many assumptions.  Since I work almost exclusively in Python, a source released and a product release are usually one and the same.  Yes, I have things they need to compile and build on the far end but that's usually nothing more than sgid wrappers and permissions they should have are dependent on the installation context.

> I also am not happy with the fact that it doesn't record execute 
> permissions, but it's not a show-stopper for me.  A properly written 
> Makefile will contain the necessary steps to change permissions as 
> appropriate anyway.  Also, the README or INSTALL text files usually 
> contains detailed instructions on how to install a package; going from 
> something like this:
> 
> 	./configure
> 	./make
> 	./make install
> 
> to:
> 
> 	./make configure
> 	./make
> 	./make install
> 
> isn't that big of a leap.  The configure make-target would be responsible 
> for ensuring sufficient permission bits to let the project configure 
> itself and compile.

it is a huge leap when you never use make in the first place.  Make is an evil abortion that should have died years ago.  when I first encountered make (circa 1980) my mentors laughed knowingly when I complained about embarrassingly bad two pages of documentation.  Their answer was to "just play with things until it works".  A criminal waste of developer time.  Since then, make has acquired more documentation but it is no more intelligible.   I have to do something with make about two or three times per year.  Each time, I spend *days* trying to puzzle out what the hell those dam funny symbols mean.  sendmail.cf syntax is better documented.

in the end, it's all about usability and make fails miserably.  Which is why I am trying to start the discussion on alternative techniques to achieve the same end result in a fashion that can be understood clearly and easily by any competent developer in a short, of time.  After all, as far as I can tell, that's one of the motivating features behind darcs.  It's making source code control easy and understandable.  It's far better than anything I've seen yet and I'm going to keep speaking up every time I see places it can be made better.

 
> The first tar ball step is a waste of time.  Just let darcs create a new 
> sandbox in /tmp or something, and directly cp the relavent files there.  
> It'll be faster.

That would work as well.  The end goal is to push the set of files that make up a release through some operation yielding set of files' which can be used for distribution.


> Note that this manner of naming patches assumes that you are the type of 
> programmer who "releases early, releases often", or put another way, 
> "commit after every step."  Note that I tag the repository every time I 
> think I've reached a milestone.  Note how often I tag: 0.1.3 was 
> "released" only 1.5 hours after 0.1.2.  Hence, people will *never* see 
> 0.1.2 on my website.

I am indeed that kind of developer.  I haven't gotten in the habit of tagging after milestone releases.  It's a good one to get into.

> 
> * The Major version number is incremented whenever a fundamental 
> architectural design point is changed, especially if it threatens 

> * The Minor version number is incremented for every interface change 
...

>   * If b = d, then the two software packages MUST be 100% compatible with 
> each other.  I can't tell you how infuriating it is to upgrade from 
...

>   * If b > d, then the version A.b.c MUST be backward compatible with 
> A.d.e, for all c and e.  The minor version is incremented when *new* 
> functionality is added to the system.  Functionality must *never* be 
...

been doing that.  Long-term habit

> NOTE: EVEN numbers are considered stable releases.  ODD numbers are 
> considered development releases.  I don't know if this convention is an 
> artifact of when Linux programmers were using CVS or not, but it is a 
> convention that seems to work with many folks.

not doing this at all.  One of the faults I was credited with in previous lives was that I never released code until it was starting to grow beard and was quite stable.  My bug count per hundred lines was roughly one or two (if I was rushed).  So, on one hand, all my releases are stable releases.  ;-)

> * The Patch Level.  This number is incremented for every set of bugs that 

I have using the patch level to indicate changes rather than patches and the minor level is only incremented once a feature set is complete and the next one is started.

for example, the previous release of camram 0.2.0.  Because I hopped straight into a new feature set, it's now 0.3.4 which means that had four bug/feature releases in the 0.3 sequence.

> Anyway, that's my personal philosophy on tagging, version numbering, and 
> releasing.  I hope this helps.

your discourse makes me more comfortable with the scheme I have.  It will work, no one will die.

thank you

---eric





More information about the darcs-users mailing list