闲云博客

关注互联网科技,记录编程点滴

2016/03/18
by Jian Yun
0 comments

自然排序的JavaScript实现

很多场合的排序都是按照字符串或数字的顺序来排序,但如果排序的内容既包含数字又有数字的时候,我们期望的排序往往是要让我们人类容易理解的那种方式。
比如下面的例子:
如果按照字符串的简单排序,下面的文件名的顺序就会是如此恶劣的:
Picture1.jpg
Picture10.jpg
Picture11.jpg
Picture12.jpg
Picture2.jpg
Picture3.jpg
Picture4.jpg
Picture5.jpg
Picture6.jpg
Picture7.jpg
Picture8.jpg
Picture9.jpg
按照我们人类的理解,很自然的期望的排序通常是下面的,正如Windows系统中的做法。
Picture1.jpg
Picture2.jpg
Picture3.jpg
Picture4.jpg
Picture5.jpg
Picture6.jpg
Picture7.jpg
Picture8.jpg
Picture9.jpg
Picture10.jpg
Picture11.jpg
Picture12.jpg

而这种排序的C#实现可以参考我早期的一篇文章《文件名智能排序的规则与算法》,这里要介绍的是JavaScript的实现。

有一个写法比较简单的开源Library,代码比较简单,但是实现效果比较符合自然排序的效果:Natural Compare

引用Natural Compare的JS文件之后就可以用了。

比如:

var array = ["Session 2", "Session A1", "Session A01", "Session 10", "Session1", "Session 1", "Session 01", "Session 001", "Session A2"];
array.sort(naturalCompare);
//排序之后的结果
["Session 001", "Session 01", "Session 1", "Session 2", "Session 10", "Session A01", "Session A1", "Session A2", "Session1"]
var a = [ {"street":"350 5th Ave", "room":"A-1021"}
        , {"street":"350 5th Ave", "room":"A-21046-b"} ];

// sort by street, then by room
a.sort(function(a, b){
  return String.naturalCompare(a.street, b.street) || String.naturalCompare(a.room, b.room);
})

 

2014/01/15
by Jian Yun
0 comments

转载:IIS在各版本windows上的并发请求限制

IIS 8 on Windows Server 2012 doesn’t have any fixed concurrent request limit, apart from whatever limit would be reached when resources are maxed.

However, the client version of IIS 8, which is on Windows 8, does have a concurrent connection request limitation to limit high traffic production uses on a client edition of Windows.

Starting with IIS 7 (Windows Vista), the behavior changed from previous versions.  In previous client versions of IIS, excess requests would throw a 403.9 error message (Access Forbidden: Too many users are connected.).  Instead, Windows Vista, 7 and 8 queue excessive requests so that they will be handled gracefully, although there is a maximum number of requests that will be processed simultaneously.

Thomas Deml provided a concurrent request chart for Windows Vista many years ago, but I have been unable to find an equivalent chart for Windows 8 so I asked Wade Hilmo from the IIS team what the limits are.  Since this is controlled not by the IIS team itself but rather from the Windows licensing team, he asked around and found the authoritative answer, which I’ll provide below.

Windows 8 – IIS 8 Concurrent Requests Limit

Windows 8 (Basic edition) 3
Windows 8 Professional, Enterprise 10
Windows RT N/A since IIS does not run on Windows RT

Windows 7 – IIS 7.5 Concurrent Requests Limit

Windows 7 Home Starter 1
Windows 7 Basic 1
Windows 7 Premium 3
Windows 7 Ultimate, Professional, Enterprise 10

Windows Vista – IIS 7 Concurrent Requests Limit

Windows Vista Home Basic (IIS process activation and HTTP processing only) 3
Windows Vista Home Premium 3
Windows Vista Ultimate, Professional, Enterprise 10

Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012 allow an unlimited amount of simultaneously requests.

原文:http://weblogs.asp.net/owscott/archive/2012/11/13/windows-8-iis-8-concurrent-requests-limit.aspx

2014/01/04
by Jian Yun
0 comments

从10个方面来提升软件开发者的效率

Ilias Tsagklis 是电信领域的一位资深软件工程师,以软件开发者的身份参与了多个应用与服务的开发工作。目前,Ilias 是 PCRF 解决方案的技术领导者。他感兴趣的领域包括多层架构、中间件服务及移动开发。近日,Ilias 撰文谈到了提升软件开发者效率的 10 个提示,这些提示很具有普遍意义,希望能为各位软件工程师工作效率的提升带来帮助。

1. 绝不要将阅读邮件作为早上的第一件事

请千万别将阅读邮件作为早上的第一件事。如果这么做了,那么你自然而然地就处于一种被动的状态之下,而不是你希望的那种积极、主动的状态。只在每天预先设定好的时间窗内查看和回复邮件,可以在午饭前,比如说 12 点到 13 点之间,然后在 16 点左右再看一次,因为这个时候你的能量可能处于下降的趋势,查看邮件并不会导致效率的降低。别担心,那些所谓的“紧急”邮件在绝大多数时候并没有那么紧急。

2. 如果可能就别去开会

在企业环境下,会议是头号效率杀手。其实道理每个人都知道,只是有人不愿意承认罢了。Dave Barry 曾说过“会议让人上瘾,导致人们过于放纵,很多公司与大型组织都是习惯性开会,否则有些人可能就无事可做了”。值得注意的是,会议会导致多人效率的同时下降。如果不是那种非参加不可的会议,那就别参加了。你可以说手头还有很多事情要做(也许事实就是如此),然后在会议后问一下参会的同事,了解一下重要的内容就行。

如果真的有必要参加某个会议(这种情况其实并不多),那么请记住下面这些原则:

在下午效率下滑时开会。 一定要设定好要讨论的主题,别随意发散。 设定严格的会议结束时间,时间到了就立刻散会。 会议结束时一定要确定好清晰的下一步行动计划。

3. 别分心

这个话题很大。在当今这个信息时代,导致我们分心的事情比比皆是,这些事情阻碍了我们正常地完成工作。我将分心划分为两类:一是我们自己造成的,二是别人造成的。

首先说说第一种。看起来很奇怪吧,但实际情况却是我们自己导致自己效率下降,甚至有时都是无意识的。这种情况比比皆是:邮件、社交媒体的“重要”通知,在不同任务间频频切换,看到 Hacker News 或是 Reddit 上的有趣新闻等等。

你应该创造这样一种工作环境,那就是在工作时没有任何东西能够令你分心。首先关掉所有通知,比如说手机上的短信、Facebook 更新等等。接下来,退出邮件应用,如果开着的话,请确保禁用掉自动发送/接收选项。然后,不要访问任何不会提升你效率的网站。我们都是极客,我相信你应该知道如何做到这一点。你可以通过比较底层的方式来编辑机器的 hosts 文件,将 facebook.com 指向 127.0.0.1,或是使用插件来临时禁用掉这些站点。我自己使用的是 Blocksite 插件。

下面谈谈第二种。你可以说上面这些令你分心的情况是由其他人造成的,不过真实情况却是你自己造成的,因为没有人强迫你访问 Twitter 或是 Facebook。第二种我称为“强迫”分心。这些情况是否出现在你身上呢?比如说,你收到经理发的一封邮件,然后他问你是否收到了,诸如此类。事实上,这种分心是比较难抵御的。有些建议,比如说戴上耳机(不过有时这样也不管用)、让来电进入语音邮箱,然后再去查看,或是在 PC 上放一张纸,写上“请勿打扰,编码中”等等。你要看看哪种情况比较适合你的工作环境,然后采取相应的行动。总的目标就是让工作能够连贯下去。

4. 前一晚准备好任务清单

你应该在前一晚准备好一个第二天要完成的任务清单。我这里指的并不是那种巨大的清单,这样根本就没效果。相反,列出两三个重要任务即可,这应该是会对项目产生重要影响的任务。比如说:如果今天搞定这两个任务,那么我的效率就非常不错了。

5. 先做重要的事

如前所述,邮件绝不应该是一天当中首先要处理的事情。那什么是首先要处理的呢?当然是清单中最重要的任务了。你应该识别出最重要的任务,然后坐下来专心解决,而不要再去考虑别的事情。理想情况下,你应该一气搞定,然后休息一会,再来做第二重要的任务。

6. 批处理并不是数据库才有的

我相信很多人都应该很熟悉批量查询的概念。一言以蔽之,你将相似的数据库查询放在一起,然后在一个请求中发送出去,这样可以提升性能。你也可以在自己的任务中应用这条原则。也就是说,将某个任务的代价、各种开销最小化。邮件、电话以及任何重复性的工作都是批处理的最佳应用场景。

7. 自动化

添加到效率工具箱中的另一个东西就是自动化。作为程序员,本质上我们生活在一个相当自动化的环境中,不过我曾看到不少开发者使用手工的方式来解决本可以轻松自动化完成的事情。人类的可靠性不如机器,特别是在面对那些无聊和不太重要的事情时。请尽可能自动化你所面对的任务。比如说通过一键的方式来执行完整的应用构建,使用一个脚本将应用部署到产品服务器上。严肃地说,请不要将你的精力浪费在机器能够更快、更可靠完成的事情上。

8. 调整工作与休息,实现效果最大化

现在来谈谈如何创建良好的工作框架这个问题。我的建议是为工作分配特定的时间,同时为休息,或是娱乐分配特定的时间。比如说,你可以使用 45 分钟的时间进行持续、集中的工作,然后花 15 分钟休息一下,看看社交媒体更新情况,阅读一些文章等。在休息时就别再盯着屏幕看了。久坐是非常不好的习惯,适当地站起身,走一走。

9. 将事情记录下来

将一切都记录下来。无论是新想法,还是新的做事方式,要知道,大脑有时是不可靠的,你需要将这一切记录下来才行。你可以将大脑看作是一个 CPU,分配给它的东西就好比是在后台启动的进程。有时,进程会挂起,不能正常工作。将事情记录下来则会解放大脑,可以让其以更加优化的方式执行任务。

10. 利用心流,专心工作

这是个圣杯,正是我们通过恰当地设计工作框架而要实现的东西,也是前面那些提示所要实现的终极目标。我敢肯定你经历过“心流”的状态,这指的是你的思维完全专注的一段时间,聚焦于特定的任务或是难题,甚至忘记了时间的流逝。头脑中除了编码,没有其他的东西存在。外部刺激也不会令你分心。你需要将自己置身于能够实现心流的状态下,尽量保持更长的时间,这将极大提升你的生产率,我敢肯定你会非常喜欢这种状态,为什么不让自己尝试一下进入这种状态呢?

2013/03/05
by Jian Yun
0 comments

源代码管理十诫

英文原文:The 10 commandments of good source control management

若是还有可以毫无偏见地涉及各个编程语言,比源代码管理软件更必要的工具,我倒是很想见识一下。源代码管理软件是我们工作的必备工具,是许多开发团队的血液。那为什么我们都会对它有所误解呢?为什么都很难理解版本控制系统的核心价值和基本原理呢?

我总结出 10 条惯例——如果你愿意也可以用“戒律”——意味着必须服从它而且从一开始很难去理解。它们与所有类型编程语言的版本控制软件都有关联。在这里我选取了 Subversion 和 .NET 的几个例子,不过它们也广泛地适用于其他的一些技术。

第一诫.如果你现在还在使用 VSS-请立刻停手

它已经死了。当然不完全对,它也存活了许多年,被全新的更实用的源代码管理工具超越之后还在苟延残喘地活着。准确地说当微软几个月后不再为其提供支持时(还是会坚持一段时间的),它才是真的死了。

平心而论,VSS 还是一个不错的工具。在 1995 年,它的光芒被像 Subversion 这样类似于 Git 和 Mercurial 的分布式软件给遮盖住了。微软表示要取代它已经好多年了。

原因是因为不支持如今的标准所导致的一系列缺陷使它一直不被看好。众所周知它是微软的悲剧系统,但不知何故它能坚持这么久,尽管它有那么多小故障,缺陷,并且不包含必需的功能(相对于今天的标准)。

第二诫.如果代码没放在源代码管理软件里,等于它不存在

每天重复读这句话——“使用源代码管理软件是唯一的有效措施”。除非你在工作时使用项目的源代码管理库来控制代码版本——否则代码等于没有存在过。

显然你曾发觉在你的本地机器上运行良好的代码在其他人那里运行的效果并不理想。是不是?他们不能获取你的最新版本,他们没法去归并代码文件,你没有正确地部署它(参考 you’re deploying it wrong)而且如果你的 SSD 硬盘坏了的话你将永远地失去你的劳动成果。

只要你保持这个心态——代码只有提交后才是真的安全,才是其他良好编程习惯的保障。你可以把你的任务划分成许多很小的单元以便你逐一提交。你需要频繁地这么做。你就不必担心你的硬件会不会出棘手问题。

不过更重要的意义是(至少对于你的团队领导来说),通过源代码管理软件可以看到你做了什么。使用图表并列出项目清单是个好方法,不过怎么知道他们实际上在做些什么?而使用源代码管理软件进行工作就能看得一清二楚了。

第三诫.要早提交,常提交,并且不要觉得麻烦

关于前面那点,避免“幻影代码”(就是只能在你的机器上看到的代码)的唯一方法是经常提交你的任务并且不要觉得麻烦。它可以解决你的问题,不过这样做也会对你的工作产生其他的影响:

1. 每个提交的修订都会为你提供一个还原点。如果你完全把代码搞砸了(没骗你,我们都这么做过),你是希望恢复到一个小时前的工作还是一周前的工作?

2. 归并文件时会出现的危险会随着时间不断增加。归并文件一直很麻烦。如果你不是每天都保持提交代码,某一天你会突然发现你和其他人的更改内容会有 50 多个冲突。你不会为此感到高兴的。

3. 它促使你把任务分离成分散的单元。通常人们都是快完成的时候才提交的,因为他们想把代码做成一个完整的逻辑单元模块。不过庞大的任务不可避免地要分离出较小的分散功能,而频繁地提交它们会使你更了解它们,你可以一个个地构建并提交。

如果你做到这些,你的提交历史不可避免地开始类似于一种半规律的样式,里面每个工作日都是在提交任务。当然不总是这样,也有停下来重构或测试,或者其他合理的活动也会中断标准的开发周期。

然而,当我在看一个独立的——尤其是完整的项目时,每当发现我们在一个标准的开发周期里,有一天或几天什么都没有做,我便会非常担忧。我之所以担忧是因为这意味着什么地方出问题了。一般不是有人正在想方设法要把问题搞定的话,就是因为卡在某个问题上而导致项目完全没有进度。无论到底是什么情况,源代码管理软件都会告诉你出现问题了。

第四诫.提交前要检查你更改了什么

往源代码管理软件里提交代码的步骤其实非常简单。(你恐怕会困惑上一条为什么说的那么麻烦。)一般只要发现文件内容有变更时都会不顾后果地把文件传上去。像这样——“我的项目根目录下有文件内容变更了,我要快点提交上去!”

如此会发生一件(或两件)事情:首先,程序员会没有意识地把目录下的垃圾代码文件也上传上去。一些人看到类似下面的窗口时,就会点击“选择全部”然后提交——这样源仓库里就会被本不应该存在的未调试的文件和其他垃圾文件给弄乱。

或者是,程序员实际上并没有检查他们更改过什么就把文件上传了。当你在工作中处理配置文件或项目定义文件时很容易就不经意把那些不想提交的文件给上传了,而且那些文件很可能就被别的程序员用到了。你真的会记住你在配置文件里的所有更改吗?

解决方法很简单:你必须在提交前立刻检查你改过什么地方。做起来其实比听起来还要容易。使用许多系统已经提供的“忽略”特性可以大幅度地减轻“不经意上传文件”的危险。你可以忽略 Thumbs.db 文件因为你压根不想上传它。你在每次修订后可能还有其他文件不想上传——那么就忽略掉它们吧!

至于文件里的更改,你通常可以使用某个流行的文本比较工具来观察差异。为什么我又要上传一次 Web.config 文件呢?

噢,我想起来了,我想把尝试密码失败的最大次数从 5 次减少到 3 次。啊,我差点没注意把一个虚拟的登录页面给上传上去了。这种在提交前做检查的练习可以让你更容易理解下一节的内容。

第五诫.写提交信息时一定要认真

这是一个古老的谚语(出处不详),大意是说“写每一条提交信息时就好象等下会读到它的人是一个斧头杀人狂,而且他还知道你住在哪里”。如果我是那个杀人狂并在研究你的代码想追踪 bug 的话,看到的提交信息全部都是“代码更新了”,小心,我会来砍你的!

我的解决办法就是解释清楚为什么要提交新的代码。每次你对代码进行更改都是有原因的。可能什么地方会崩溃。可能客户不喜欢现在的主题颜色。可能你仅仅要调整一下构建配置。无论是什么,这都是有原因的而且你要把原因用文字保留下来。

为什么?这样做的原因有很多,而且在不同环境下各不相同。举个例子,使用“归属”特性或其他类似的功能显示出谁改了代码那些地方。如果我不记得 18 个月之前我对项目的 Web.config 文件改过什么地方或者我为什么要改动应用程序的设置,是因为我没有在当时留下一个适当的提交信息,而现在会非常简单:

这是一个可以随时观察代码更改的软件的一种。无论我像下面那样想了解一个文件的完整更改历史,还是只想知道团队昨天做了什么,留下一个描述性的相关记录意味着只要不经意一瞥就能知道是什么情况了。

最后强调一下,当调试遇到错误时提交信息的重要性是无法估计的。举个例子,在你的集成环境里的最后更新的地方可以找到出错的原因。我的例子是非常显而易见的,不过把信息表示出来可以把很多棘手的问题变得极好解决。

把这条牢记于心,这里列出一些提交信息的反面教材:

1. 可恶

2. 能跑了

3. 解决了一些混帐问题

4. 解决了

5. 改进了一点 bug

6. 上传了

7. 排字错误

8. 修订 1024

好的,我从 Stack Overflow 网站的哪些是你写过的最差劲的提交信息(译者注:帖子已经被删除了,原因难道是出现了脏话?)帖子里选取了以上内容,不过它们和我以前看过的提交信息并不相同。它们没有告诉你有关代码更改的任何有效信息;它们都是垃圾信息。

关于提交信息最后要注意的是;同一个程序员之后提交信息绝不能和前面的完全相同。原因很好理解:你向源代码管理软件提交文件是因为对于上一个版本的代码有东西改变了。你现在的代码和之前的已经不一样了,如果你的提交信息是完整准确的,理论上就不能和前面的相同。如果是相同的(可能有时真的会这样),日志就会难以阅读,因为没有办法区分两条提交有什么区别。

第六诫.你必须自己提交你的更改内容——不能委托他人

听起来很奇怪,但它的确会发生,我看过不止一次,最近的是上周。情况是这样的,源代码库被视为极高的地位。因为很多原因,团队会去追求完美代码的洁净和单一。为了保持这种神圣的状态,代码只能由某个领头的程序员来提交,他在提交前会小心地整合,审查并(大概会)调整改善代码。

即使站在很远也能很容易评价这个方案。不太频繁的提交(可能一周几次),只有一个脱离团队其他程序员的人来提交,而且不可避免地在这段漫长的无提交时期里会有人的工作会导致项目混乱。非常非常不好。

这样做会有两个错误:首先,源代码管理软件并不意味着它里面代码是神圣不可侵犯的;至少在整个开发周期里是这样的。它应该是团队频繁整合文件,在出错时还原到正常并且共同解决问题的地方。不是自始至终都要这样做,只有在应用程序周期的发布时期为了达到某种状态时才做的。

另一个问题——并且真的是极为关键的——站在程序员的视角,这样等于你压根没有在用源代码管理软件!它等于没有同伴之间的代码整合,没有还原,提交信息没有负责人,什么都没有!你们仅仅是在自己的象牙塔里各自写各自的代码然后等着未来顺便某一天把它交给领导就完事了。

不要这样做。千万不要。

第七诫.一定要管理好数据库的版本

这一点是我们都知道必须要做的,但是很多人觉得它麻烦。问题是很多(或者是大部分)应用程序没了数据库就不能运行。如果你没有管理好数据库,那你实际上做的就是一个不完整的完全无用的应用程序。

几乎所有的版本控制系统的工作就是管理好文件系统内的文件。它只是对像 HTML 页面,图片,CSS,项目配置文件和其他在文件系统的独立单元这类典型应用作用较大。问题是它确实没法在与程序有关联的数据库上起到作用。你总不能替换掉庞大的数据库,把所有旧数据文件和包含一大堆对象和数据日志文件统统换掉。这样会让版本控制系统完全乱成一堆。

Red Gate 公司开发的智能的 SQL Source Control 使这个情况得到了合理解决。我在去年写的Rocking your SQL Source Control world with Red Gate 这篇帖子里详细说明了这款软件,所以我现在就不多说了;总之就是数据库管理现在会非常容易了!

老实说,如果你没有管理好你的数据库版本,你的开发会伴随着很大的问题。在更改数据库的时候没有源代码的管理,没有还原点,并且很难和团队密切合作。使用数据库版本控制系统可以使开发更轻松。

第八诫.编译生成的文件不要放进源代码管理软件里

简单地说:在编译运行项目时自动生成的结果文件不要放进源代码管理软件里。对于 .Net 开发的程序员,主要是”bin”和”obj”文件夹里通常会出现的 .dll 和 .pdb 文件。

为什么?因为如果你这样做,你的同事会恨你的。这意味着每当他们从版本控制系统里取下最新文件时会让你的编译文件覆盖掉他们的。这是一个双重噩梦(你绝不能这样做),在他们下一次编译时就会出问题。而且只要他们重新编译后再把编译文件重新上传上去,同样的问题会以相反的方向再发生一次,不过这次你是受害者。你肯定不想这样的。

当然另一个问题就是这样做很浪费。这会浪费源代码管理服务器的硬盘空间,会浪费带宽并会通过网络发送时一直潜伏着,而且这样做造成的不可避免的冲突会极度浪费你的时间。

所以我们继续使用之前提到的“忽略”方案。只要把像”bin”和”obj”这样的路径直接忽略掉,一切就真的很轻松了。只要按照这种方法做一次,所有人都会感到开心的。

其实我在写 pre-commit hooks 时就说到了在版本控制的服务器上不能提交此类文件。当然如果有值得这么做的原因的话,只有这种情况下你可以上传。不过我倾向于不要这么做以免将来会导致某个人在更新时发生冲突。

第九诫.不要上传你自己的用户设置

老实说,我认为很多人没有注意到他们把自己的私人设置文件上传到源代码管理软件里了。这样会出现的问题是:许多工具会产生只管理你自己本地配置的文件。它们只对你有用而且通常和其他人的私人设置文件相异。如果你把它们上传到源代码管理软件里,很快你就会覆盖掉其他人的私人设置文件。这样并不好。

这是一个典型的 .NET 程序的例子:

假如你没有立刻清理的话,多余出来的就是扩展文件和类型描述,也就是 .ReSharper.user 文件和 .suo(Solution User Option, 解决方案用户选项)两个文件,它们只属于你,对其他人无效。我们要再次使用忽略方案来处理。

第十诫.附属文件也要集成在一起

这是十诫中的最后一条也是最最重要的一条。当应用程序需要外部的附属文件存在才可以正常运行的话,把那些文件也都放进源代码管理软件里!人们倾向于犯的错误是,在他们拥有自己设置文件和本地附属文件的环境里一切都表现得很好就把东西都上传了,之后觉得没问题了就不管了。但是其他人不能从源代码库里找到同样的附属文件的话,所有东西都会悲剧性地报错。

我想到这点是因为今天从源代码库里拖出某个旧项目并运行它时出现了这样的画面:

我以为 NUnit 一直在机器上,但这次没有。幸运的是使用 NuGet 可以快速解决问题,但是没有附属文件的话,不是每次都可以用同样的方式就能轻松解决的。有些情况下,它们并不是公开的,你很难全部都获取到。

我从源代码管理软件里取出的项目运行时之所以会报错是因为我发现”C:\Program Files…”路径下丢失了附属的文件。我花了不少时间用来联系最后更改过它的那个人(很明显他在世界上另一个很远的地方),获取了那个文件,把它放进”Libraries”文件夹下并把它上传到了版本控制系统里,这样下一个提取文件的人就不需要再这么麻烦了。

当然另一个重要的原因是,如果你在任何一种集成环境里工作时,你的构建服务器不一定安装了那些库。你必须有那些文件才能运行。Doug Rathbone 最近写了一篇很好的关于这点的文章 Third party tools live in your source control (源代码管理软件里的第三方工具)。并不是非要那样做(我们也善意地评价了效果),不过它确实是一个很方便的建议。

因此推荐每个人第一天就把程序运行所需要的东西全都放进版本控制系统里。

总结

没有哪一条是很难理解的。老实说,它们都很基础:尽快并频繁地提交,确认你提交的东西改了什么,还有东西一定要放进版本控制系统里,解释清楚你的提交信息和确保是你自己提交的,不要忘记数据库和不要忘记附属文件。还有就是不要使用 VSS:)