Oren Eini

aka Ayende Rahien

Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,582
|
Comments: 51,207

Copyright ©️ Ayende Rahien 2004 — 2025

Privacy Policy · Terms
filter by tags archive
stack view grid view
  • architecture (611) rss
  • bugs (450) rss
  • challanges (123) rss
  • community (379) rss
  • databases (481) rss
  • design (895) rss
  • development (641) rss
  • hibernating-practices (71) rss
  • miscellaneous (592) rss
  • performance (397) rss
  • programming (1085) rss
  • raven (1448) rss
  • ravendb.net (532) rss
  • reviews (184) rss
  • 2025
    • June (4)
    • May (10)
    • April (10)
    • March (10)
    • February (7)
    • January (12)
  • 2024
    • December (3)
    • November (2)
    • October (1)
    • September (3)
    • August (5)
    • July (10)
    • June (4)
    • May (6)
    • April (2)
    • March (8)
    • February (2)
    • January (14)
  • 2023
    • December (4)
    • October (4)
    • September (6)
    • August (12)
    • July (5)
    • June (15)
    • May (3)
    • April (11)
    • March (5)
    • February (5)
    • January (8)
  • 2022
    • December (5)
    • November (7)
    • October (7)
    • September (9)
    • August (10)
    • July (15)
    • June (12)
    • May (9)
    • April (14)
    • March (15)
    • February (13)
    • January (16)
  • 2021
    • December (23)
    • November (20)
    • October (16)
    • September (6)
    • August (16)
    • July (11)
    • June (16)
    • May (4)
    • April (10)
    • March (11)
    • February (15)
    • January (14)
  • 2020
    • December (10)
    • November (13)
    • October (15)
    • September (6)
    • August (9)
    • July (9)
    • June (17)
    • May (15)
    • April (14)
    • March (21)
    • February (16)
    • January (13)
  • 2019
    • December (17)
    • November (14)
    • October (16)
    • September (10)
    • August (8)
    • July (16)
    • June (11)
    • May (13)
    • April (18)
    • March (12)
    • February (19)
    • January (23)
  • 2018
    • December (15)
    • November (14)
    • October (19)
    • September (18)
    • August (23)
    • July (20)
    • June (20)
    • May (23)
    • April (15)
    • March (23)
    • February (19)
    • January (23)
  • 2017
    • December (21)
    • November (24)
    • October (22)
    • September (21)
    • August (23)
    • July (21)
    • June (24)
    • May (21)
    • April (21)
    • March (23)
    • February (20)
    • January (23)
  • 2016
    • December (17)
    • November (18)
    • October (22)
    • September (18)
    • August (23)
    • July (22)
    • June (17)
    • May (24)
    • April (16)
    • March (16)
    • February (21)
    • January (21)
  • 2015
    • December (5)
    • November (10)
    • October (9)
    • September (17)
    • August (20)
    • July (17)
    • June (4)
    • May (12)
    • April (9)
    • March (8)
    • February (25)
    • January (17)
  • 2014
    • December (22)
    • November (19)
    • October (21)
    • September (37)
    • August (24)
    • July (23)
    • June (13)
    • May (19)
    • April (24)
    • March (23)
    • February (21)
    • January (24)
  • 2013
    • December (23)
    • November (29)
    • October (27)
    • September (26)
    • August (24)
    • July (24)
    • June (23)
    • May (25)
    • April (26)
    • March (24)
    • February (24)
    • January (21)
  • 2012
    • December (19)
    • November (22)
    • October (27)
    • September (24)
    • August (30)
    • July (23)
    • June (25)
    • May (23)
    • April (25)
    • March (25)
    • February (28)
    • January (24)
  • 2011
    • December (17)
    • November (14)
    • October (24)
    • September (28)
    • August (27)
    • July (30)
    • June (19)
    • May (16)
    • April (30)
    • March (23)
    • February (11)
    • January (26)
  • 2010
    • December (29)
    • November (28)
    • October (35)
    • September (33)
    • August (44)
    • July (17)
    • June (20)
    • May (53)
    • April (29)
    • March (35)
    • February (33)
    • January (36)
  • 2009
    • December (37)
    • November (35)
    • October (53)
    • September (60)
    • August (66)
    • July (29)
    • June (24)
    • May (52)
    • April (63)
    • March (35)
    • February (53)
    • January (50)
  • 2008
    • December (58)
    • November (65)
    • October (46)
    • September (48)
    • August (96)
    • July (87)
    • June (45)
    • May (51)
    • April (52)
    • March (70)
    • February (43)
    • January (49)
  • 2007
    • December (100)
    • November (52)
    • October (109)
    • September (68)
    • August (80)
    • July (56)
    • June (150)
    • May (115)
    • April (73)
    • March (124)
    • February (102)
    • January (68)
  • 2006
    • December (95)
    • November (53)
    • October (120)
    • September (57)
    • August (88)
    • July (54)
    • June (103)
    • May (89)
    • April (84)
    • March (143)
    • February (78)
    • January (64)
  • 2005
    • December (70)
    • November (97)
    • October (91)
    • September (61)
    • August (74)
    • July (92)
    • June (100)
    • May (53)
    • April (42)
    • March (41)
    • February (84)
    • January (31)
  • 2004
    • December (49)
    • November (26)
    • October (26)
    • September (6)
    • April (10)
RavenDB - High-Performance NoSQL Document Database
  previous post next post  
Mar 28 2008

Frequent check ins frequent integration

time to read 1 min | 37 words

A few days ago there was a thread in the ALT.Net mailing list about the frequency of check ins.

Here is my opinion in this matter:

image

Tweet Share Share 15 comments
Tags:
  • Development

  previous post next post  

Comments

Jeremy Gray
28 Mar 2008
19:29 PM
Jeremy Gray

I'm a big fan of frequent check-ins as a result of fine work decomposition, however I do wonder about changeset 17205: Depending on your interpretation of "do not use", that shouldn't have been checked in, as it broke the project. Not so much in a "broke the build" sense, rather in a "broke any other dev that checks out as of 17205 sense."

Ayende Rahien
28 Mar 2008
19:39 PM
Ayende Rahien

No, the last checking refers to users who might want to use this.

At the moment, it works, pass all the tests, but it not verified enough for me to be comfortable to release to users.

Josh
28 Mar 2008
19:45 PM
Josh

Maybe I just missed a post with the explanation, but why are you spending so much time on the svnbridge project?

Ayende Rahien
28 Mar 2008
19:48 PM
Ayende Rahien

Josh,

I am getting paid to do so.

Jeremy Gray
28 Mar 2008
20:08 PM
Jeremy Gray

@Ayende - I figured that'd be the case. :)

Pierre-Marc
29 Mar 2008
00:58 AM
Pierre-Marc

From 5 am to 7 pm ????

Ayende Rahien
29 Mar 2008
01:18 AM
Ayende Rahien

No,

Thu 08 PM - 5 AM

Fri 1 PM - 9 PM

Pierre-Marc
29 Mar 2008
01:25 AM
Pierre-Marc

hihi, anyways from my point of view, I try to split my expected work of the day in 4 to 6 tasks and check-in after each one.

Ayende Rahien
29 Mar 2008
01:30 AM
Ayende Rahien

I tend to commit whenever I have a stable system

pb
29 Mar 2008
02:39 AM
pb

I check in as frequently as him. For me, as long as it is passing all tests and I have completed a unit of work, I check in. I like being able to just blast everything with an undo checkout on the whole project if something doesn't work out and too many tests get horked up.

Frans Bouma
29 Mar 2008
09:47 AM
Frans Bouma

I also favor frequent check-ins. The biggest feature of a sourcecontrol system is that you have a history: you can rollback to a known good state. So even if you have to make 3 changes to the same code file, if these 3 changes are actually 3 different bugfixes for example: check in after each change.

Another thing which might be considered is checking in after a day of work, even if the code doesn't build. If it doesn't build: check into your own branch, add #error and #warnings where you were at and what to change the next time you're working on that code. Of course, when you add #error and #warning lines, be sure to check into a different branch, but that's what they're for anyway :). The advantage of this is that if your own box crashes, you stil have your work. When you're done you merge with the trunk (that's why there's a merge feature ;))

Ayende Rahien
29 Mar 2008
09:53 AM
Ayende Rahien

I agree, except the checking in to a private branch.

That certainly work, but I tend to prefer generating a patch file and storing it on the server as opposed to a branch.

pb
29 Mar 2008
16:31 PM
pb

We actually have ours setup as a branch called Production instead of Main. You don't check in broken code to that, ever because hotfixes are done right in that branch very quickly without having to check with anyone. We all work off a network drive that is snapshotted hourly and nightly so there isn't much concern about losing code if you don't check in for a while but you can shelve if you want. And we don't leave if something isn't working either.. :) Working state to working state makes life easier - and sleep easier too and isn't too hard if you take a little piece at a time.

Igor Brejc
29 Mar 2008
19:04 PM
Igor Brejc

There's another interesting discussion I happened to be involved in yesterday about the future of CI which also touches on the frequency of commits and the "trunk development" vs. "branch per task development" paradigms:

http://codicesoftware.blogspot.com/2008/03/continuous-integration-future.html

Fervent Coder
06 Apr 2008
20:53 PM
Fervent Coder

I can say that I check in at least that frequently. Being on team development, when I am ready to check in I integrate locally first, build, run the tests and make sure they pass. Then I check in.

Being on TFS, I also don't keep the solution or project files checked out longer than to add a reference or a new file (classes mostly). Once added, both get checked in and then the new class gets checked back out for me to add the functionality to. This behavior doesn't break the build and gives the added bonus of not causing others to have to merge more than necessary.

Comment preview

Comments have been closed on this topic.

Markdown formatting

ESC to close

Markdown turns plain text formatting into fancy HTML formatting.

Phrase Emphasis

*italic*   **bold**
_italic_   __bold__

Links

Inline:

An [example](http://url.com/ "Title")

Reference-style labels (titles are optional):

An [example][id]. Then, anywhere
else in the doc, define the link:
  [id]: http://example.com/  "Title"

Images

Inline (titles are optional):

![alt text](/path/img.jpg "Title")

Reference-style:

![alt text][id]
[id]: /url/to/img.jpg "Title"

Headers

Setext-style:

Header 1
========
Header 2
--------

atx-style (closing #'s are optional):

# Header 1 #
## Header 2 ##
###### Header 6

Lists

Ordered, without paragraphs:

1.  Foo
2.  Bar

Unordered, with paragraphs:

*   A list item.
    With multiple paragraphs.
*   Bar

You can nest them:

*   Abacus
    * answer
*   Bubbles
    1.  bunk
    2.  bupkis
        * BELITTLER
    3. burper
*   Cunning

Blockquotes

> Email-style angle brackets
> are used for blockquotes.
> > And, they can be nested.
> #### Headers in blockquotes
> 
> * You can quote a list.
> * Etc.

Horizontal Rules

Three or more dashes or asterisks:

---
* * *
- - - - 

Manual Line Breaks

End a line with two or more spaces:

Roses are red,   
Violets are blue.

Fenced Code Blocks

Code blocks delimited by 3 or more backticks or tildas:

```
This is a preformatted
code block
```

Header IDs

Set the id of headings with {#<id>} at end of heading line:

## My Heading {#myheading}

Tables

Fruit    |Color
---------|----------
Apples   |Red
Pears	 |Green
Bananas  |Yellow

Definition Lists

Term 1
: Definition 1
Term 2
: Definition 2

Footnotes

Body text with a footnote [^1]
[^1]: Footnote text here

Abbreviations

MDD <- will have title
*[MDD]: MarkdownDeep

 

FUTURE POSTS

  1. Webinar: Think inside the database - 9 hours from now
  2. RavenDB GenAI Deep Dive - about one day from now
  3. fsync()-ing a directory on Linux (and not Windows) - 4 days from now

There are posts all the way to Jun 09, 2025

RECENT SERIES

  1. Webinar (7):
    27 May 2025 - RavenDB's Upcoming Optimizations Deep Dive
  2. Recording (16):
    29 May 2025 - RavenDB's Upcoming Optimizations Deep Dive
  3. RavenDB News (2):
    02 May 2025 - May 2025
  4. Production Postmortem (52):
    07 Apr 2025 - The race condition in the interlock
  5. RavenDB (13):
    02 Apr 2025 - .NET Aspire integration
View all series

RECENT COMMENTS

  • Scooletz, Page faults when working with data that is greater than RAM is not an uncommon issue for us. One of the reasons ...
    By Oren Eini on Recording: RavenDB's Upcoming Optimizations Deep Dive
  • What a massive presentation! As a person who spent some time with a db written in .NET I can strongly relate to some points. ...
    By Scooletz on Recording: RavenDB's Upcoming Optimizations Deep Dive
  • I’d love to learn your thoughts on SPANN https://arxiv.org/abs/2111.08566 that with centroids and keeping the posting lists s...
    By Scooletz on Comparing DiskANN in SQL Server & HNSW in RavenDB
  • Joel, The DiskANN paper talks about it being viable for more than a billion vectors datasets.  In such a scenario, it would ...
    By Oren Eini on Comparing DiskANN in SQL Server & HNSW in RavenDB
  • Do you know why they chose DiskANN? These things are usually about tradeoffs but it seems DiskANN is just worse in every way.
    By Joel on Comparing DiskANN in SQL Server & HNSW in RavenDB

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats
}